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TECHNICAL PAPER 


WORKING ON THE BOUNDARIES: PHILOSOPHIES AND PRACTICES 

OF THE DESIGN PROCESS 

I. INTRODUCTION 


“There are three great sources of help to the designer. The first is practice, what has 
been done already, in living organisms, or most often by other designers. The second is 
principles, of design, derived by reflection or by abstraction from a wide knowledge of 
practice or both. The last is the philosophy of design, which manifests itself as a single 
strong thread of sometimes rather abstract reasoning running through certain designs, 
usually having an apparent inevitability. It is rare, but perhaps should be more common; 
certainly, it is difficult to explain, even with examples, but can be recognized.” “Invention 
and Evolution, Design in Nature and Engineering,” by Michael French. 1 

The title “Working on the Boundaries” is borrowed from a Harvard business journal citing the 
complex interfaces managers must face in our current culture, in not only dealing with international bound- 
aries, but also with organizational boundaries and delegations. And so is the design process complex! The 
design process interactions are seemingly endless: systems, subsystems, disciplines, techniques, tools, 
facilities, training, etc. Their interfaces are compounded through a hierarchy of organizations, leadership, 
specialists, customers, schedules, financing, etc. 2 3 

It is recognized that each of these interfaces has been bounteously discussed and reported sepa- 
rately and in combinations by numerous and excellent authors in a variety of industries and institutions. 
However, this document is a result of special requests from several members of the aerospace community 
for an overview of all major interaction and interface fundamentals experienced in the design process of 
some of the largest aerospace projects. 

The design process is a blend of classical procedures and evolving philosophical principles and 
practices in the ever-changing and challenging environments of customer expectations, new technologies, 
and constraining economics. An engineering product builds on those consistent and proven practices and 
philosophies selected in the design process. This report endeavors to identify and illuminate a few recur- 
ring design process principles published, experienced, and observed that lead to successful aerospace 
products. 

Basic to the design process is the overall understanding of the product’s missions life-cycle and its 
partitioning into manageable critical parts. Launch vehicle and spacecraft design and development exem- 
plify the processes. Figure 1 depicts the design process decomposition into a hierarchy of systems, sub- 
systems, and implied disciplines analysis and design tasks requiring clear definitions of interfaces and 
requirements flowdowns. As depicted in the figure, the integrity of the system can only be determined 
when the decomposition is reversed, combining the elements back into the system and determining its 
integrated characteristics. The design of a launch vehicle, spacecraft, or satellite illustrates the application 
of this process to a very complex aerospace product incorporating space unique design processes in com- 
bination with many standards and innovative design techniques emerging from the aerospace and com- 
mercial industries. The emphasis of the process is to ensure that the highly interactive element and compo- 
nent products satisfy their mission role as a part of the space system through design criteria, interdis- 
ciplines and interface performances robustness, and costs. Leadership, human skills, innovations, and 
creativity that is brought to the process are the backbone of the design methodology. 


DESIGN PROCESS 


PRODUCT INTEGRITY 



COMPARTMENTALIZATION 

-SUBSYSTEM 

•COMPONENT 


COMPARTMENTALIZATION 
BY DISCIPLINES 
-STRESS 
-THERMAL 


Figure 1 . System design process. 

Design of aerospace systems is much more challenging today due to global competition, shifting 
design emphasis from performance to cost and operations. Total design must deal with at least six factors: 
quality, operations, reliability, cost, performance, and usefulness. In other words, the customer’s needs 
must be understood and met, which may not be mutually exclusive; cost affects quality, quality affects 
reliability, and so forth. Introduction of cost and operations into the process creates problems for designers 
that they are not accustomed to dealing with, and often there are not many adequate metrics available for 
making their judgments. The process of design is, therefore, a series of trades between conflicting 
requirements imposed on a competitive product. The complexity of this interaction is depicted in figure 2 
for a liquid propulsion system illustrating many of the tightly coupled interactions. 

There is no black and white approach to the design process. In general, each organization must 
develop its own approach that is most compatible with the end products. However, some general princi- 
ples may be tailored to help develop the process. The overriding principle seen throughout the design pro- 
cess in figure 1 is the dynamics of a systems focus, which must permeate the total process, becoming evi- 
dent at each level of the design from the total hardware system to the smallest component, from concept to 
operations, and from design to manufacturing. These dynamics require leadership, communications, inte- 
gration, empowerment, and customer expectations. Results should be a low-cost, high-performance, reli- 
able, robust, and operable product. 

As the design process emphasis and flow are product specific, the presentation topics selections 
and sequences are arbitrary to the design procedure. Topics were chosen for their common occurrence in 
successful aerospace products, from many referenced texts and documents, and from authors’ experi- 
ences, investigations, studies, and general observations with some of NASA’s largest carriers, payloads, 
and facilities. Examples are biased in mechanics because of its dominance and phenomenal progression in 
most aero products and because of the authors’ roots in that discipline. 
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Overlap and Interdependency 
of Design Requirements 


Figure 2. Interacting design requirements. 

General philosophies and criteria of the design process are discussed. Their influences are woven 
through the various systems and disciplines analyses and interactions (fig. 2) throughout all design phases 
of the systems engineering process, and particularly noted in the design cycle section. The design process 
is briefly illustrated on experienced aerostructural systems with the expectation that the interested reader 
may pursue the referenced documents. Many authors have greatly influenced design methods of which 
Pye in “The Nature of Design,” 4 and Pugh in “Total Design” 5 are outstanding examples. 
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II. PHILOSOPHY 


“Philosophy is the set of the sails and the rudder that determines the path and the 
port (product). People are the prime resource that determines the set of the sails. Thus, the 
philosophical statements implement the design process which in turn creates the product. 
These philosophical statements start at the top governing the overall program, becoming the 
navigational lights for the derived philosophies developed by each element, component, 
design, and operations teams. The statements not only deal with the technical side, but they 
encompass organizational life, manufacturing, and operations as well.” Robert Ryan 


A. Organizational Philosophy 

The organizational culture (paradigm) determines the outcome of the product. Therefore, the 
organizational philosophy must first deal with empowerment. Are decisions made only at top management 
levels, or are they pushed to the lowest working levels, thus empowering people? If decisions occur at the 
top, then hierarchy structures are set up in the general pattern of the past. Mintzberg 6 discusses the many 
different forms of organizational structure and their underlying philosophy. Empowerment to the lowest 
level is the most powerful. It opens opportunities to many innovative and creative designs that not only 
release the potential to reduce management levels, but is a fertile bed for the use of teaming (section XI). 
Organizational philosophy must also address growth patterns, education, future directions, etc. 


B. Philosophy of Design 

Prevalent today is a philosophical concept coming out of the Japanese quality movement which 
emphasizes up-front penetration and costing. This concept rings out the system design and comprehends it 
in order to reduce cost and problems downstream, thus building in product quality and reliability. The 
quality lever shown in figure 3 illustrates this philosophy. The idea is to place the money and effort where 
it has the greatest payoff. Early in a program, the payoff can be as high as 10 to 1. Later in development, it 
is no better than 1 to 1 . In operations and production phases, the leverage is negative, which creates large 
cost factors. Implied is a change in the awards system that awards for problem prevention instead of 
problem solutions . 

Attached to this design philosophy is the concept selection philosophy. Pugh 5 states that the 
approach of concept selection is most critical. The best engineering effort cannot totally right a poor con- 
cept selection. An interesting example occurs in the Russia Energomash liquid rocket engine company 
where a design is not started or a final concept is not selected until a thorough exploration program has 
been completed. The design philosophy is to use physical models that are directed toward some perform- 
ance or concept goal derived from current systems. These models are highly instrumented and are first 
tested over a range of conditions, and are then tested to failure. Only when several of these models have 
made it through the test program is the design of the new engine system started. Pugh’s 5 philosophy 
selects the concept of converging and diverging studies, which narrows, combines, expands, and narrows 
again. The process continues until the combined concept selection converges to the best solution. As Pye 4 
has so aptly said, “All designs are a compromise, you must take some of what you do not want to get what 
you want.” The essence of the design process is how one makes this compromise. 

Another design philosophy has to do with the considerations of variations and unknowns and to 
what extent they are considered. Is the design a deterministic or probabilistic statement? Also criteria are 
fundamental to design, as well. the philosophy of cost and reliability. One very important design philoso- 
phy is the role that failures play. Petroski expounded this philosophy in his book “Design Paradigms” 7 
and states that the design process must consider indepth all potential failure modes. This is 
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Product 



Figure 3. Quality lever. 

true even when the new product is a moderate scaling up of a current successful system where the slightest 
design change can introduce effects that lead to failure totally unexpected. Therefore, all designs must 
consider all potential failures and their consequences. Is this objective best accomplished through failure 
effects and modes analyses (FEMA) and critical items list (CIL) analysis? Inherent in failure avoidance 
design is the redundancy philosophy. If a design has redundancy, is the design fail safe, fail operational, 
fail safe, or fail operational, fail operational, fail safe? Undoubtedly many parts of a design cannot be made 
fail safe and require more indepth considerations of failure drivers and margins. Most primary structures 
fall into this design domain. 

Fundamental to design philosophy are the philosophies that are really co-dependent; the philosophy 
of sensitivities, and the philosophy of robust design (section VI). Sensitivity philosophies are in two cate- 
gories: (1) the need to assess and quantify sensitivities of a system to parameter variations within specified 
standard deviations, or to the extreme values; and (2) the philosophy of designing the control response of 
the system to sensitivities (parameter uncertainties). 


C. Design Tools 

In this age of information explosion and implosion, the use of physical and analytical tools are 
even more important than ever. The large amounts of design information must be collapsed or reduced to 
symbols or top-level parameters for digestion, understanding, and communication. This process, how- 
ever, means that detailed information is replaced by top-level symbols and parameters in order to effi- 
ciently engineer projects. Two resulting philosophies are: (1) engineers must be well grounded in the fun- 
damentals of their special discipline, continually thinking in terms of the detailed physics of the problem 
(computer black-boxes can never replace this), and (2) engineers must thoroughly understand a wide 
scope of available tools (physical, analytical, and computational), and they must further appreciate a tool’s 
potential application and modification into other disciplines. The process requires a constant verification of 
the underlying assumptions, constraints, etc., in order not to improperly apply design tools; a major 
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problem among cookbook engineers blindly using tools and accepting results. This problem applies to 
analysis, computation test, and manufacturing. 


D. Operations 

Operational philosophy is integrated throughout the design process. Examples include shipping 
parts and assembly at launch site, automatic checkout and health monitoring, robustness, or detailed 
inspection. The decision of the operations philosophy has its greatest effect on design, cost, and reliability. 
Robustness implies first understanding the sources and effects of sensitivities, and then designing to con- 
trol or reduce the response to them. Robustness also implies designing away from the performance cliff 
such that complex analyses and detailed inspections are not required, thereby reducing costs and opera- 
tions. 


The philosophy or role that manufacturing and operations play in the design process is reflected in 
the quality and cost of the product. It is imperative that these elements be a fundamental part of the design 
process so that the product can be built and operated successfully. In other words, do not design a new 
product then pitch it over the fence and expect efficient manufacturing and operational design phases. Inte- 
grate the knowledge of operations up front in the design process. Adjusting the design for operating at a 
later date results in high cost, lower quality, and complex operations. Design for simplicity is a great 
philosophy. 


E. Verification 

Verification philosophy is broad in scope and embodies both the development analysis and testing 
and the final verification of each system and component. Because verification cuts across all disciplines, 
system, subsystems, elements, components, and design data, philosophy can have many facets applicable 
to each specific area. Elements of verification philosophy are not standard, but should at least address 
testing and analysis. 

Testing includes prototype versus protoflight, proof, off-nominal, failure modes, sensitivities, 
analytical model variations, response characterizations, etc. The merits and demerits of each are well 
documented and are not repeated here. However, every project or discipline must carefully consider all 
design essentials and form applicable testing philosophies. Testing to failure identifies basic failure modes 
and margins and is a very prudent philosophy. Additionally, it is very important to adopt the philosophy of 
modeling the expected response prior to the test to guide the test design, instrumentation, monitoring, etc., 
and to correlate and correct the model using the test findings for future applications. This step is so funda- 
mental and essential to the mission and to learning that it should never be compromised. Also, test 
assumptions and boundary conditions must be constantly challenged and verified. The use of constancy 
and similarity is a part of this philosophical statement. 

Analysis includes the role and philosophy of analysis in the design and verification, and it estab- 
lishes, not only the people resources required, but also the facilities, equipment, and software codes. With 
the current capability of computers and engineering codes, reliance on computational engineering is 
becoming a primary force in design, verification, and operations. The elements that must be dealt with are: 
(1) accuracy, (2) penetrations, (3) role, (4) verification benchmark to other codes or to test, etc., and (5) 
commercial or private specialized codes. For example, if one of the design goals is to minimize analysis, 
then the design must be simple and robust enough to reduce the level of penetration required. Regardless 
of the philosophy chosen, analysis is no better than the assumptions used and the data inputted. Assump- 
tions must, therefore, be constantly challenged and evaluated. The following is a quote from an unidenti- 
fied publication, yet the basic philosophy is profound. 

“The essence of modeling as we see it, is that one begins with a nontrivial work 
problem about the world around us. We then grapple with the not always obvious problem 
of how it can be posed as a mathematical question. Emphasis is on the evolution of a 
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roughly conceived idea into a more abstract but manageable form in which inessentials have 
been eliminated. One of the lessons learned is that there is no best model, only better ones. 

The model is only a suggestive metaphor, a fiction about the messy and unwieldy 
observations of the real world. In order for it to be persuasive, to convey a sense of credi- 
bility, it is important that it not be too complicated and that the assumptions that are made be 
clearly in evidence. In short, the model must be simple, transparent, and verifiable. We 
have allowed ourselves to be guided by these precepts in choosing the examples.” 

Input data fall under the same sensitivity. The classical cartoon in figure 4 illustrates the concept. 



Figure 4. “So that decimal point was a fly speck.” 


There are many other philosophical statements in the design process. For example, what is the role 
of cost, operations, and performance? If the philosophy is performance driven, then in all likelihood cost 
will increase and operations will become more complex. Conversely, if the philosophy is operations, and 
is cost driven, then performance can suffer. It is important to understand that once a philosophy is chosen, 
then the task becomes one of identifying all the drivers that influence it. 

Another needed task is fracture control. Is it ignored or a fundamental part of design? Fracture 
control drives not only design, but manufacturing quality and operations (maintenance). Also thermal pro- 
tection system (TPS) design is a major part of any space vehicle design. Is it passive or active, part of the 
basic structure or added? Control is another fundamental task. If the design is a launch vehicle, should it 
be stabilized aerodynamically (fins, etc.), or stabilized through active control? The same type of question 
follows for control load relief. In this case, induced additional failure modes are traded for structural 
weight. 


Many other tasks require philosophical statements. Many are derived from top-level philosophies. 
Each program must list the tasks, then define the philosophies. Eventually, philosophies may be captured 
as requirements. It should be pointed out, however, that some philosophies cannot be defined up front, 
but must evolve as the development phase unfolds and become derived requirements. 


7 


III. ROLE OF CRITERIA IN DESIGN AND MANAGEMENT 


“Optimal performance needs administration for order and consistency (formal), and 
leadership (informal) so as to mitigate the efforts of administration on initiative and creativ- 
ity and to build team effort to give these qualities extraordinary encouragement. The result, 
then, is a tension between order and consistency on the one hand and initiative and creativ- 
ity and team effort on the other. The problem is to keep this tension at a healthy level that 
has an optimizing effect.” “Servant Leadership,” by Robert K. Greenleaf. 


A. Criteria: Definition and Scope 

The design, verification, and operation of space systems are extremely challenging, emphasizing 
on one side, manned flight safety, on the other long duration spacecraft, many with very stringent pointing 
accuracy or other specific requirements. 8 Requirements specifications and standards must be developed to 
accomplish these many faceted programs that technologically push the state-of-the-art in all aspects of the 
project. In general, these vehicles and spacecrafts are one-time or limited items driving toward unique 
craftsmanship versus routine design and manufacturing, which greatly complicates the design process. 
The philosophy, definitions, and scope of these technical legally binding requirements significantly 
influence quality products. 

A companion set of documents, designated “guidelines,” that provides the lessons learned is very 
important to project development, but is not legally binding. Figure 5 is an attempt to flow down these two 
different types of criteria essential to project design and operation. (Note: the term “criteria” designates the 
combined set of formal requirements and informal guidelines. Sometimes the term is used in a more 
narrow sense to mean “discipline requirements,” but is used here in the broader sense.) The left-hand side 
of the figure encompasses all the legally binding requirements (what’s), while the right-hand side shows 
the nonlegally binding information (how’s). The legal requirements separate initially into three categories. 
First is performance requirements (mission peculiar). They are the “what’s” that spell out such things as 
manned, unmanned, reliability, payload, orbits, mission profiles, lifetime, reusability, etc. Performance 
requirements drive the configuration selection, size, thrust, etc. The second set is classified as design 
requirements. Design requirements have two categories, standards (industry approved hardware or pro- 
cesses) and discipline requirements that include special processes, margins (stability, safety factors), 
redundancy, fracture control, and response limits. The third group of requirements are normally called 
derived requirements. These are the requirements that evolve during design and operations that are neces- 
sary for the system to meet the performance requirements. Load relief control is one example of this 
group. All these requirements are flowed down into the contract controlling documents: contract end items 
(CEI’s), interface control documents (ICD’s), data requirements documents (DRD’s), certificate of qualifi- 
cations (COQ’s), and verification requirements. Because the final product must meet all legal require- 
ments, they must be verifiable. Requirements become the basis for the design reviews (audits) and opera- 
tions. 


The right-hand side contains all the lessons-leamed documentation that contains technology, data 
bases, handbooks, procedures, tools, etc., that greatly enhance communication and knowledge transfer, 
which is so important to space project success. These informational documents are not legally binding, but 
serve as guidelines. 

Legally binding criteria are therefore defined as the requirements governing the design, verifica- 
tion, and operation of a project. Programmatically, the system must meet these requirements or a waiver is 
required for acceptance. Figure 6 shows this approach and how the requirements are not only used to steer 
the design, but become the standard governing die project verification and acceptance. During verification, 
the product must be shown to meet or exceed these requirements. 
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Figure 5. Role of requirements in product design. 
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Legal requirements must be simple, unambiguous, concise, and direct, providing order to the 
engineering process; but not overpowering to where the requirements stifle creativity and remove respon- 
sibility. The balance between legal requirements (formal organizational structure) and creativity (informal 
organizational structure and leadership) is probably the most challenging task engineering faces. Legal all- 
encompassing requirements produce order but, if excessive, remove responsibility, kill innovation, 
suppress opportunity to find the best solution, and stifle creativity. 

The model developed has a sharp line of demarcation between legally binding requirements and 
informal guidelines, providing the basis for the healthy-level tension that optimizes. Greenleaf 9 stated the 
case well in emphasizing the creation of teamwork. Teamwork is the method for insuring the quality prod- 
uct. It is mandatory that government and industry, project, and engineering work as a team. If any group 
becomes the priest (the judge) excessively binding the others in a legal manner, the team effort is destroyed 
along with creativity. Space engineering is always pushing the edge of technology, requiring the optimum 
development of creativity in order to meet the combined performance, risks, and cost goals. Hence, a 
constant awareness and struggle is required to balance between the legal requirements and creativity 
(informal) of the individual. This task is one of the highest priority tasks. Requirements and standards are 
needed for all facets of the project. They start with the general performance requirements and evolve to 
include management, finances, all design disciplines, manufacturing, operations, and maintenance. In 
summary, they tell the “what” and the “when” of the project, defining what the customer desires, while the 
informal ensures communication and information transfer without repeating the mistakes of the past. 

The content, structure, and philosophy of criteria have far-reaching influences on the evolution and 
success of the project. It is easily recognized that design parameters, margins and robustness, are directly 
affected by the criteria imposed. Less apparent is the pervasive effect that criteria have on the relationships, 
teamwork, balance, and management within the project framework. 

Criteria quite naturally set the technical design point — the balance between performance, reliability, 
and operability. Furthermore, beyond directing the technical evolution of a design, the philosophy and 
content of the criteria used can enhance or retard the nature of the relationships among the engineering and 
project manpower elements. 

Also, the tone of contractor-customer relationships can be greatly influenced by the method in 
which the criteria are deployed; ranging from an at arms-length adversarial relationship to that of a coop- 
erative, teaming effort. Discussions of these influences are given in subsequent sections. 


B. Misuses of Criteria 

Requirements can be misused in several ways. In one extreme, they are so loose and ill-defined 
that they do not provide order to the process. In the other extreme, they are too restrictive, specifying not 
only the necessary requirements, but including procedures, guidelines, codes, and many times, undue 
constraints such as geometric, mass, cost, and schedule. In the first case, there are no order or standards, 
hence the product has no form, may become very costly, and may not meet the customer’s needs. The 
over-specified case also results in a costly product that ends up compromising the customer’s performance 
goals because proper trades cannot be accomplished and the system optimized. Features not accounted for 
in the design must be covered in maintenance and operations. This not only increases the cost and com- 
plexity, but generally increases operations turnaround time as well. 

Although the space shuttle exemplifies many correct uses of criteria becoming the world’s greatest 
space system, it is also a prime example of constraints misused. The complexity and cost exceeded all 
predictions along with some performance compromises. The performance requirements, manned, reuse, 
etc., in conjunction with early geometric, weight, and cost constraints drove the design to very high 
derived performance requirements. For example: 55-mission life, 109-percent engine thrust, etc., dictated 
high-performance structures (welded, light weight), high-energy concentration, and the like. The result is 
a very costly maintenance and operations system. Inspections are numerous, as well as the hardware 
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change-out, and the refurbishment required to maintain safety is immense. In other words, the space 
shuttle evolved into a performance-driven instead of a cost-driven design, which resulted in costly main- 
tenance and operations in order to maintain reliability and safety. 

An ever present trap in using criteria is the dependence on criteria to accomplish a good design 
while relaxing sound engineering practice. In the final analysis, skilled personnel applying good engineer- 
ing thoughts and practices are the roots of quality products. This is especially true in the aerospace indus- 
try where technology is pushing state-of-the-art, requiring innovation and creativity of the highest order. 


C. Proper Use of Criteria 

Pugh, in his book “Total Design,” speaks of the role of the product design specifications (PDS), 
which corresponds to the “specifications” block of figure 5. He says that “the PDS is the mantle envelop- 
ing the whole design core activity. It is the document or documents that unambiguously delineate all the 
legally binding requirements. It is dynamic rather than static. It is an evolutionary, comprehensively writ- 
ten document which, upon completion of the design activity, has itself evolved to match the characteristics 
of the final product. It (PDS) must be comprehensive and unambiguous, otherwise the designer will fill in 
the gaps based on feeling and experience.” Pugh further states that, “at the end of the design activity, the 
product must be in balance with the PDS. It sets the design in context, representing as it does a compre- 
hensive set of constraints that are always in a unique combination.” 

Criteria then are of two types. First and foremost, as Pugh says, it is the legally binding mantle 
developed to make the product conform to the customer’s needs and good engineering practices. The 
second set is not legally binding. The “informal” (guidelines) are used to properly evaluate the trades for 
concept selection and, during detailed design, drives out the formally derived requirements. They are very 
important because these criteria become the standards against which decisions are made and guide the 
design, etc., by providing the lessons learned, handbooks, and other communications gathered through 
practical engineering and past space programs. 

All organizations use criteria in these two roles; however, as was discussed above, many times 
criteria are misused, creating problems. If criteria can be misused, then the question that arises is. What is 
the proper role and use of criteria? Criteria must provide the balance between order and control and free- 
dom to draw out creativity and innovation (fig. 7). 

CONSISTENCY RESPONSIBILITY 

ORDER CREATIVITY 



Figure 7. The balancing act. 

In accomplishing this task, criteria must also balance the product optimally between performance, 
cost, and reliability. Criteria must be derived and selected for each while maintaining political viability, 
also a balancing act. Space vehicles, by definition, are always performance-critical and performance can 
overdrive the product. Great care must be exercised to develop a balanced set of criteria in these areas. 
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The most optimum product is determined by conducting proper trades between the potential con- 
figuration concepts (for example, liquid versus solid propellants), materials potentials (steel versus 
aluminum versus composites, etc.) and the manufacturing/fabrication possibilities (casting, extruding, 
etc.). This relationship must be considered simultaneously requiring properly defined, balanced criteria 
jointly derived by all disciplines involved (fig. 8). 



Figure 8. Triangle of product design. 


On the surface, it appears that these diverse areas can be treated separately. However this is not the 
case. In fact, these areas are highly interactive, often in a contradictory way. They must be balanced 
together properly to produce the appropriate product (fig. 9). 



Figure 9. Proper use of criteria. 
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When considered in this manner, proper use of criteria performs many functions: 

1 . Management tool 

2. Sets the design boundaries 

3. Sets the verification limits 

4. Enhances communication and technology transfer 

5. Controls the design optimization, trades, and concept selection 

6. Sets operational constraints and procedures. 

In order to properly perform these functions, criteria must cover all aspects of the product. Criteria 
includes, but is not limited to: 

Performance 
Environments 
Maintenance 
Transportation 
Manufacturing 
Assembly 
Size, weight 
Materials 
Finish 
Cost. 

The management approach must be consistent with the criteria. The criteria controls the product 
design, thus management must provide the framework and business control within which the design 
operates, providing resources, common objectives, understanding, and project direction. Managers are 
responsible for organizing and planning design reviews, operational plans, etc. The next subsection will 
deal with the philosophy and approach for the management concept. 


Shelf life/storage 

Service life 

Standards 

Processing 

Testing/verification 

Documentation 

Operations 

Reliability/availability 

Schedule 


D. Project Management as Influenced by Criteria 

The management approach for a space project can be reflected in, or can be a reflection of, the 
philosophy adopted in establishing its criteria. The content of criteria and the methods used in their devel- 
opment can set the tone for relationships among the various parties involved: project management, 
engineering, and business management on both sides of the customer-contractor interface. 

Excessive criteria, which over-specify the “how-to’s,” not only short-circuit creativity in the 
attempt to arrive at the best design, but can also drive a wedge between engineering and project manage- 
ment groups. Over specification results in excessive waiver and traffic deviation, and leads to “lawyering” 
versus good engineering. Under specification, while less common, is likewise to be avoided to preclude 
major downstream shortfalls. The proper balance of criteria enhances a healthy and productive relationship 
between engineering and project management. 
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If criteria are developed unilaterally and are imposed arbitrarily on the contractor, the two parties 
are set at odds from the beginning. In its extreme form, this arbitrariness encourages an adversarial 
customer-contractor relationship. At best, it promulgates a “throw-it-over-the-fence” approach, where 
problems are not addressed as a team, but wait on the formulation of a design review or other major legal 
milestone. 

A much more proactive approach is to make criteria development a joint effort between contractor 
and customer. In this effort, both parties work together to tailor the specifications to the needs of the par- 
ticular project with a goal of achieving the ideal balance of control and innovation described earlier. The 
joint effort produces joint ownership of the criteria and lays the groundwork for teamwork and communi- 
cation. This relationship leads to a proactive approach to project evolution, with early problem identifica- 
tion and resolution. Teamwork brings all available resources to bear toward successful project maturity. 

A healthy teamwork environment is not without disagreement and tension. Rather, tension is to be 
expected because of the different emphasis and subgoals of each participant. When all parties are com- 
municating and working toward the overall objective, there is room for disagreement. One must draw a 
distinction between creative and destructive tensions. A tension exists between the subgoals of perfor- 
mance, reliability, cost, and schedule. If openly recognized, communicated, and dealt with in a teamwork 
environment, this tension can be creative tension, which in fact directs the evolving design to its ideal 
balancing point. Likewise, tension is natural between engineering and project management, or between 
customer and contractor. Dealing with these natural tensions in a teamwork approach can provide the 
creative balance to direct the evolving project to its ideal operating point. 


E. Proper Development of Criteria 

Proper development of criteria is based on two fundamental concepts: (1) breadth, which covers all 
necessary areas, and (2) minimum, to produce the optimum design. This subsection will deal with the 
breadth question while section VI will deal with ways of achieving the minimum required set. 

L Performance Requirements . The performance requirements identify how a product is to func- 
tion. Since the origin of the basic performance requirements is the customer, the performance demanded 
should be defined. Space systems have many performance requirements, most of which are unique to that 
particular system such as aperture and pointing accuracy for a telescope, payload size and weight to speci- 
fied orbits, manned or unmanned, cost, reliability, reuse (how many times), operational turnaround, to 
name a few. Quality function deployment (QFD) is an excellent tool for developing and flowing these 
requirements down throughout the project. 

These requirements are very critical to the design because they determine what is to be done. 
Overly tight requirements may drive the economics of the system out of the range of affordability. Yet, if 
the requirements are necessary to accomplish the job, then technology must be considered as well as cost. 
Space projects as a rule require the extension of some technology to meet the performance requirements. A 
general applicable rule is: do not start a project that requires the development of more than one major tech- 
nology. 


2. Derived Requirements . In the process of concept selection and detail design, performance 
requirements or criteria dictate additional requirements necessary to meet the project’s goals. These are 
commonly called derived requirements because they occur as the project evolves. Examples include launch 
vehicle load relief control trades between structural weight, performance loss, and cost, and the Pogo sup- 
pression system that stabilizes the vehicle from launch propulsion structural dynamics coupling. The list 
goes ad infinitum and evolves from all design disciplines such as manufacturing, transportation, assembly, 
and operations. 
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Derived requirements are, therefore, mandatory for the product success; however, they should 
include only those that are mandatory; not nice to have, overly complex, or of a patchwork quilt design. 
Derived requirements should evolve to be a coherent part of the design. In other words, they must buy 
their way in. Great care must be taken in properly testing, evaluating, and baselining these requirements. 
Once baselined, derived requirements must be designed and verified as all other subsystem and component 
requirements. 

3. Design Requirements . Design requirements fall into two basic categories: (1) the standards, and 
(2) discipline requirements. They are the controlling factors in the design. 

Design requirements spell out, in unambiguous terms, the margins in all disciplines (safety factor, 
lifetime, performance, etc.), the process controls, environments, documentation, and probability required 
to produce an acceptable product. They flow down into the documents such as ICD’s, CEI’s, etc. Pugh 
states that design requirements detail the performance demanded or likely to be demanded and should fully 
define all aspects of design. Design requirements not only play the role of providing the standards by 
which the product is verified and operated, but they also serve as a management tool. Performance, in this 
case, is not just how fast, how slow, or how much, but includes all the specifications for the product, 
including but not limited to, verification, testing, environments, margins, life, maintenance, transportation, 
manufacturing, assembling, materials, and reliability. In summary, design requirements function in two 
roles: (1) a management tool and (2) legal controls for the design boundaries. As stated earlier, design 
requirements bring order to the process without killing creativity, and ensure that the product achieves the 
goals assigned it. 

4. “What’s” Versus “How-To’s.” Lessons Learned. Guidelines . The “what’s” spell out the neces- 
sary conditions that must be met in a design, such as how long, when, speed, cleanliness, environments, 
etc. These are in general mandatory and legal, setting the basics for a design. Good design dictates that a 
comprehensive set of “what’s” be established and adhered to. As was stated earlier, these “what’s” should 
be binding on the project and enforced by the management. 

“How-to’s” are the history, the lessons learned, technology, and procedures. Generally, the “how- 
to’s” are not a part of the contractually binding requirements; however, they serve a very useful purpose 
both to enhance communication and document good things to do. Their influence is not to be discounted, 
in that “how-to’s” are a voluminous source of information that has a profound influence on the project 
design cycle. There are some cases when the “how-to’s” are so overriding that they must become a part of 
the contractual requirements. The sources of these lessons are contained in handbooks, technical papers 
and reports, monographs, and — more importantly — in the experience base of the individuals making up 
the organization. 


F. Restructuring Criteria to Full Potential 

Requirements and guidelines are the foundation for good products. It is imperative that the 
requirements (legally binding) particularly be derived in a meticulous and thorough manner. Require- 
ments/criteria not only control the design but, in the end, become the specification for the product, provid- 
ing the basis for operations (use). This dictates that requirements must be verifiable. A good design is a 
rule-based design. The prime question is, how is this correct set of criteria developed? 

Clearly, the derivation of requirements must be based on lessons learned, standards, project man- 
agement approach, performance requirements, and technical requirements. It must cut across all areas of 
design and operation concerns for all disciplines involved in the project. Consideration should be given to 
FMEA’s, robustness, redundancy, margins, cost, and schedules. 
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Further, requirements/criteria definition should be a product of joint effort between the customer 
and the contractor. Pugh devotes one chapter in “Total Design” to the derivation of the PDS, recognizing 
the importance of criteria. Requirements are usually written to include guidelines, procedures, and imple- 
mentation schemes. This approach is not correct. Requirements should be very concise and specific with- 
out justification or guidelines, and should be based on sound engineering understanding. However, there 
is a need for guidelines, procedures, and implementation schemes including engineering equations, com- 
puter codes, instrumentation plans, test approaches, etc. These “how-to’s” should be produced as separate 
documents and not as part of the requirements. 

Thus, all criteria must be based on basic principles and tools, using teamwork of government and 
contractors, being a project that has true joint ownership, and utilizing sound systems engineering, concur- 
rent engineering, and continuous process improvement. All areas from materials, concept selection, fabri- 
cation, to operations must be approached in this evolutionary manner. The role of criteria is then to provide 
order to the process without stifling creativity and innovation — the main ingredient of space system 
design. Criteria developed in this manner should satisfy all the pervasive influences, without binding 
creativity, to produce the order required to achieve a low-cost, quality product. As important as criteria 
(requirements) are, it should be warned that there is also a balancing of criteria and good design engineer- 
ing. The best criteria without sound engineering produces poor products, as does sound engineering with 
poor criteria. Space product design is a multifaceted process that requires great skill in balancing between 
them. Criterion is only one facet of design engineering and must not exist in a vacuum, but consider all 
dimensions of the product. 


IV. SYSTEMS GUIDELINES 


“It is only when we understand (or feel we understand) a system in depth, when 
our model is extremely adequate, that we can sometimes grant ourselves the luxury of con- 
fusing the model with the modeled system. This is precisely what we require from a good 
theory, that it allows us to replace the system with the model, so that we can theorize rather 
than experiment.” “The Philosophy Behind Physics,” edited by Luis Ocla Pena and Peter 
Hodgson. 

This section applies modem quality management principles to a conventional systems design 
analysis process 10 11 to provide least life-cycle cost, efficient operability, and high reliability designs. 
Suggested quality techniques include Steward’s systems information flow matrix method, quality leverage 
principle, quality through robustness and function deployment, Pareto’s principle, Pugh’s selection and 
enhancement criteria, and other design process procedures. Quality performance at least-cost can be 
realized through the systems engineering process, competent concurrent engineering teams and the bril- 
liance of their technical leadership. The systems design process develops options to satisfy firm user 
requirements and progresses down to component design for low-cost quality performance, manufacturing 
and operations. This section briefly identifies applications of a total vehicle system design, while the load 
cycle (section XII) primarily discusses in more detail the design process of structural systems. 


A. Systems Design Process 

Design is conceived of a demand for a product that performs a need — easily, reliably, and afford- 
ably. From this concise premise evolve design processes and analytical techniques to translate demands 
into engineering requirements and solutions. The systems design process provides an orderly transforma- 
tion of payload objectives into a detailed vehicle systems design through three continuous and correlated 
phases in the systems engineering process: 12 13 concept, definition, and design (fig. 10). 
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Figure 10. Systems design process. 

A total system decomposes into tiers of systems, elements, and components throughout these 
phases. Each tier decomposes further into design parameter tasks that expand and interact with systems, 
elements, or components in each respective tier. Tasks identify design parameter requirements, develop 
design options to satisfy requirements, perform tradeoffs, and formulate criteria to select the best option 
leading to final design, specifications, and plans of systems, elements, and components. The focus in the 
process is to discover where and how total quality management (TQM) techniques 14 may be adapted in a 
vehicle configuration design analysis, and extend the similar techniques to vehicle systems, elements, and 
components. For brevity, only one application of each technique will be identified and discussed in the 
design process. 


B. Systems Concept Phase 

In designing launch vehicles, the concept phase is a first-order development of payload require- 
ments and vehicle systems options to satisfy these requirements. The concept phase also represents the 
greatest quality leverage, 15 as previously discussed in section II. In the scale of quality leverage, the 
earlier the control of critical requirements, the more timely and efficient are the solutions and modifications 
(fig. 4). The more congruously and completely the options are analyzed, the more effective and successful 
are the concept selection and development. A missed superior option or poorly selected concept results in 
costly back-tracking or in remedial technology bottlenecks. 


C. Payload Requirements 

Because the front-end phase is so crucial to converging on a successful minimum cost program, 
the user needs must be thoroughly researched, understood, and evaluated. Sometimes designers’ concepts 
that are technically brilliant are at variance with market needs. Many methods exist for evaluating user 
needs leading to solutions. Flugel’s conversion steps 16 provide understanding and help to differentiate 
between users’ true demands and other quality requirements. User demands are defined into potential 
payload packages by commonality of orbital altitude, inclination, and insertion requirements, and by 
weight, size, shape, maximum ascent acceleration, readiness, and missions traffic. The QFD method 17 is a 
team effort using flow matrices to convert user demands into standard payload package sizes and 
characteristics. 
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Figure 1 1 is a basic matrix format used to make more orderly and visible the behavior of parts as a 
function of the behavior of other parts in a system. Applied to QFD, payload demands are decomposed 
into rows of “what” functions to be satisfied. “How” and “how much” columns represent independent 
payload package accommodations. “How much” a payload demand is satisfied in a given package may be 
traded across the rows to reduce and optimize the number of payload packages. Extra columns may be 
added to compare the findings with delivery competition. 
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Figure 1 1 . QFD process. 

Payload requirements further define mission, schedule, and launch readiness reliabilities, which 
translate into cost to the customer. Also, reliability of delivery success is directly related to insurance cost. 
Slipping a delivery schedule may deny the experimenter an observation opportunity, which degrades the 
effectiveness of the experiment and increases the cost of personnel staffs, inventory, and storage to the 
user. Delaying launch countdown may degrade biological experiments and may require refurbishment. 

Innovations to reduce the time and cost of integration and inspection reviews of payloads, and 
simplifying vehicle mission planning and preparations are invaluable marketing assets. For example, inte- 
grating experiments into a family of containers, or shrouds, independent of the launch vehicle site and 
finally stacking the containers on a ready-to-go vehicle provide a quick change-out capability to the pay- 
load. The concept reduces the launch vehicle integration time, which decreases the operational turnaround 
time. 


D. Vehicle Concepts 

Payload package requirements that drive vehicle systems requirements include payload sizes, mass 
characteristics, reliabilities, and orbit insertion conditions. By assuming a common reference low-Earth 
orbit (LEO) and a standard ascent trajectory, performances of a wide variety of launch vehicle concepts 
delivering the total set of payload packages may be evaluated. Payloads may be accommodated by a com- 
mon vehicle or through evolutions of a core vehicle. Core vehicle concepts are developed in three steps 
(loops), each successive step generating more design parameters and tasks, introducing new vehicle sys- 
tems and elements, and providing more information and interactions. 

The first step combines propellant systems and staging schemes into a wide variety of vehicle con- 
cepts to satisfy payload delivery energy requirements. The difference between LEO injection velocity and 
the Earth launch site velocity establishes the propulsion energy, delta velocity (DV), that the vehicle must 
provide the payload to achieve LEO. The vehicle model assumes a point mass and a kick-impulse method 
with various staging schemes, mass fractions, and propulsion specific impulses (Isp) as a function of the 
required DV. Each assumed value is a source of iteration that interacts with other design parameters and 
must converge through the design process. Providing generous sacrificial margins to each initial assump- 
tion will reduce the iterations of product performance design with increasing system demands. 
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The propulsion system selection is the most critical driver of vehicle performance, size, and relia- 
bility, and it dominates the development, manufacturing, and recurring operational costs. Choices of 
propulsion systems and staging options include hydrocarbon, hydrogen, solid fuels, and combinations in 
a single or more stages burning in parallel or in series. Vehicle stages may be reusable or expendable. 
Variations in each of these options provide a wide spectrum of propulsion Isp, propellant-to-payload mass 
ratios, and combinations producing many vehicle concepts. A matrix format of figure 12 may provide the 
visibility of the combinations with each “how” column defining an independent vehicle. 
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Figure 12. Propulsion system selection options. 

While concepts are generated by individuals, best selection and enhancement are accomplished by 
concurrent engineering teams. Concurrent, or simultaneous engineering is a team composed of all essential 
disciplines involved in the analysis and selection of design concept, materials, manufacturing, processes, 
and major operations. It is the focus and integration of related design disciplines, knowledge, and experi- 
ences drafted into mixed team assignments. Concurrent engineering develops selection criteria to assure 
quality performance, reliability, and operations at low life-cycle costs. 

Of the many available option selection techniques, one suggested by Pugh compares one option 
with another and enhances it in the process. The technique uses a simplified matrix of criteria versus 
options for complete visibility and scoring. It uses one option as a datum to compare all other options, 
with a “plus” or “minus” compliance with selection criteria. All evaluated concepts are then reviewed for 
possibly modifying them to pass the criteria. Weak options are eliminated until one strong concept 
persists. 

User requirements and their accommodations represent one side of the balance; cost to implement 
them represents the other. Designers have a unique responsibility to minimize overruns by completing 
design analyses at each design phase, controlling requirements buildup through all design phases, reduc- 
ing sources of engineering bottlenecks, and managing costs through models based on historical cost fac- 
tors. Weight is a design parameter routinely calculated and available through most of the design process. 
Weight may be correlated to size and performance and is the most often used metric to estimate cost. 18 
Thrust, power, and flow rates also characterize size and performance of specific systems that may be 
related to systems cost. Facility costs are related to space and equipment. Cost varies inversely with pro- 
duction quantities. Complexities directly increase cost. Advancing state-of-the-art increases the costs of 
learning new phenomena, potential bottlenecking, and new facilities. Cost models change with time 
because of inflation and technology improvements, and they are scaled accordingly. Cost factors are diffi- 
cult to quantify in the earliest phase, but become increasingly more definable with each subsequent phase. 
Though cost estimates based on system similarity are often sufficient for a concept phase, costing in the 
final design phase begins with the lowest component and accrues to assembly level. 

The second step assumes a vehicle stick model for each selected concept, having lumped masses, 
point thrust, and an aerodynamic envelope ascending through a standard trajectory and worst case space 
environments. Using figure 11, vehicle systems are distinguished by the “how” columns as flight, 
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propulsion, structures, avionics, and facility systems. These systems may be orderly decomposed into 
interacting design parameters and listed as “what” parameters. The matrix intersection of the “how” system 
and the “what” design parameter identifies tasks. Narratives address “how much” requirements, solution 
options, cost analyses, operations scenarios, and criteria and rationale for selection. Each “how” column 
defines a vehicle system. 

As systems decompose into more design parameters, their interactions across the systems are 
visible, as shown figure 13. However, parameter interaction within each system and their feedback flow 
and order of analysis become more difficult. Steward 19 developed a method for managing the interaction 
of tasks and the information flow in a system. The decomposed tasks are listed and numbered in the order 
in which they must be completed before the next task may begin. Predecessors of each task are listed in 
two adjacent columns. In one column are the sensitive predecessors whose estimated errors cause large 
effects on the tasks that follow, and the second column lists insensitive predecessors. This same informa- 
tion is charted into a precedence matrix with rows and columns numbered by tasks. Tasks are then 
reordered in the sequence in which they are to be accomplished through a procedure of partitioning and 
tiering. The process can be computerized and the matrix further developed into change control and verifi- 
cation tools. 
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Figure 13. Vehicle parameters and interacting systems matrix. 

Stick model configurations are derived and constrained by systems interactions/boundaries. 
Propellant tank diameters are restrained by logistics, payload size, or first stage engine arrangements, but 
are otherwise optimized for minimum inert weight. Stage lengths are approximated from propellant 
mixture ratio, volumes, and diameters. Total vehicle length is estimated from stage stacking arrangements 
and payload sizes. Masses are lumped at stage centers of gravity. The vehicle envelope is modeled with 
cones and cylinders to estimate aerodynamic drag and center-of-pressure. The total lift-off thrust is 
determined from the total vehicle weight and an assumed lift-off ratio acceleration to control launch pad 
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clearance during ground wind disturbances. The final stage thrust is limited by the payload maximum 
ascent acceleration requirement. The most critical single driver is the propellant system selection, which 
sizes major structural components and defines overall vehicle configurations, facilities, and operations. 
The engine is the single most expensive element to manufacture and operate. This step concludes with 
upgraded requirements and selection of third step candidates through criteria formulated by concurrent 
engineering using QFD techniques. 

This third and final concept step iterates and upgrades all vehicle systems and elements of selected 
concepts based on step two upgraded requirements and interactions leading to one or two candidates for 
the definition phase. Ascent DV losses are converted to propellant masses, and tanks are resized and 
arranged to optimize load paths. Stage configurations and weights are refined through limited structural 
analysis. Vehicle control laws are incorporated into standard trajectories to define loads and thrust vector 
rates. Dynamic load drivers, such as structural interfaces, attachments, and stiffness at load concentration 
points, are identified and optimized. Engine sizes are estimated from numbers required to satisfy lift-off 
thrust and acceleration. Arrangements and base heating are addressed. Engine out and throttling require- 
ments are also considered. Preliminary wind tunnel results are incorporated into aerodynamic, aeroheating, 
and thermal protection concepts in the final performance iteration. Vehicle systems and elements are 
detailed to a level appropriate for identifying operational facilities and life-cycle costing. 


E. Systems Definition Phase 

The definition phase is a continued development of selected vehicle concept systems and elements 
through the progressive decomposition of the elements into components and design parameters. Tasks are 
identified and flowed through figure 13 matrices and Steward’s techniques as before. Tasks suggest 
requirements that generate solution options, tradeoffs, and selections, using similar TQM and QFD 
methods addressed in the concept phase. Requirements defined in this phase are documented as specifica- 
tions that must be verified by final analyses and preliminary tests. Concurrent engineering is expanded to 
recognize interacting issues and develop criteria, in all design disciplines, with increased awareness on 
operations, reliability, and costs. 

Operations and associated facilities are the most often underestimated accommodations. 20 Design 
schemes and scenarios to reduce recurring operations costs should be traded, firmly established, and 
incorporated into vehicle systems, elements, and components in this phase. Reliability of vehicle 
performance and of ground and flight operations is cost correlated. It costs to increase reliability, but 
marginal failures cost even more. Pareto’s principle 21 is an effective approach to improve reliability at least 
cost. Pareto observed that 20 percent of parameters cause 80 percent of the results. The top 20 percent 
most significant parameters may be identified through histograms of their relative sensitivities to the ideal 
expectation and risk. 

Among the many tradeoffs performed in this phase, liquid propulsion system simplicity and 
robustness are the premier challenges. Increasing the engine size will reduce the number of engines per 
stage and reduce the complexity of integrating multiple units, all of which increase reliability and reduce 
operations costs. High Isp and thrust-to-weight ratio are primary considerations for reusable engines. 
Moderate margins and high manufacturing costs are traded with low operating cost and durability. 
Expendable engines trade large design margins to provide high reliability and low manufacturing costs. 

Structural elements must accommodate all propellant and pressurant gas requirements. Additional 
tank volume is required for propellant consumed during engine startup before launch release, for residual 
fuel bias to avoid depletion before the oxidizer, and for minimum pump head required to prevent pump 
cavitation. Tank pressure trades the heat exchanger energy increase required to increase the pressurant 
flow rate and pressure with the benefit of increased pump suction head. Increased pressurant increases 
residual weights. 
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The avionics system consists of electronic devices, instruments, and software that sense and affect 
guidance, navigation, controls, communications, and monitoring. Monitoring should include engine 
startup, shutdown, thrust, thrust vector control, propellant and pressurant management, and thrust valve 
controls. Health monitoring checks temperatures, pressures, accelerations, and electrical services. Selec- 
tions should consider performance, reliability, labor, and operations improvements and costs. Standard 
interfaces, hardware, and software reduce operations costs. 

Facilities and vehicle systems interactions and tradeoffs are mission-specific and include special 
handling equipment, hazardous materials treatment, seal and connection leakage prevention and testing, 
robustness, and automation. 

The definition phase should provide complete sets of preliminary design definitions of launch 
vehicle systems and interfaces, elements of each vehicle system and interfaces, components, and schemes 
for payload and stage attachments and separations. Definition sets should show positive margins in per- 
formance, weights, costs, and systems preliminary test results. This phase should include natural and cal- 
culated induced environments, systems tradeoffs and rationale, and systems and elements electronic 
mockups. It should project cost estimates to develop and maintain major supporting technologies, skills, 
facilities, inventories, logistics, special handling equipment, data links, operations scenarios, etc. 

Preliminary design definition should include centrally stored electronic layout drawings and speci- 
fications, and standard references. Specifications are legally binding and are the basis for managing per- 
formance, reliability, schedules, and costs. The balance between legal documents and creativity is an 
implied objective of the design process. Standard documents should be condensed and tailored uniquely 
for each specific program, and not left to contractors to legalistically interpret applicability which often 
results in undue protectionist conservatism as discussed in section III. 

F. Design Phase 

The design phase is the final system analysis phase and the most comprehensive. It is also the low- 
est in design quality leverage and most consequential. The analysis must penetrate all final component 
designs for compliance with all tiers of specifications and requirements, and must assess and assure that all 
integration conflicts and issues are identified and resolved through all levels of components and systems. It 
must further analyze and modify detailed component designs and their integrations for high quality per- 
formance, manufacture, verification, and operations at lowest cost. Quality analysis goes beyond specifi- 
cations. It looks to design effects on these four hardware applications downstream and exercises the final 
quality leverage on hardware design. 


G. Quality Performance 

Quality requires performance to be robust and least sensitive to environmental fluctuations . 22 
Phadke’s robust design method may achieve that goal by specifying the ideal performance and identifying 
quality characteristics, which is the difference between the output and the targeted performance values. 
Joint leakages are a common source of quality loss in launch preparations and delays, having a smaller-is- 
better characteristic target. Response time, structural weight, material flaws, and corrosion are other 
examples. Material strength and specific impulse are larger-is-better examples with naturally limited tar- 
gets. Normal-is-better may be characterized by a fixed target for static problems and an output-propor- 
tional-to-input moving target for dynamics problems. Conditioned power source, sensors, and servo- 
motors are common examples where the standard deviation is minimized first and the mean is then 
adjusted to the target value. 

Three of the most common types of design parameters that influence quality characteristics are sig- 
nal, noise, and control. Signal parameter levels are set by the user to produce the desired functional 
response, such as speed, thrust, and frequency. Noise parameters are difficult or expensive to control. 
They deviate from target values through unit-to-unit variation resulting from manufacturing processes and 
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They deviate from target values through unit-to-unit variation resulting from manufacturing processes and 
through deterioration from aging and wear. Control parameters are specified by the designer to minimize 
noise parameters that may or may not change the cost of the product. Tolerance factors are control parame- 
ters that affect costs. 

Orthogonal array techniques reduce the number of parametric variations and combinations required 
to determine the most optimum control parameter adjustment. Tolerance design may be necessary to bring 
the performance to target. Tolerance design trades off quality loss due to variations in performance with 
cost increase to tighten manufacturing tolerance and cost of higher grade materials and components. 
Parameters independent of quality characteristics are adjusted to cost, reliability, operations, or other 
quality considerations. 

Robust design aims for the widest operating environment, low grade components and materials, 
and widest manufacturing tolerances and variations for least product cost and operation. Developing total 
quality into detailed design incorporates downstream customer design expectations in manufacturing, veri- 
fication, and operations. 


H. Quality Manufacturing 

The systems design analysis role is to integrate performance parameters resolved in the quality per- 
formance application with manufacturing demands to increase yield and reduce costs through reduction in 
unit-to-unit parameter variations, optimized quality control system, and reduction of rejection rates of 
defective parts. If product design parameters are too complex, the product will be difficult to reproduce. If 
the product is hard to assemble, then it will incur assembly errors. Manufacturing customer expectations 
must be considered in the detailed design in which the customers are processors, machinists, welders, 
assemblers, handlers, etc. 

Akao’s QFD method may be combined with robust performance demands for adaptation to designs 
for quality manufacturing. The method decomposes a product down to its parts level and generates manu- 
facturing quality demands that satisfy quality performance design parameters developed in quality per- 
formance application (fig. 1 1). The “what” required by performance demand is related in matrix form to 
the “how” the product is to be manufactured. Quality “what” demands are correlated with strongest quality 
“how” characteristics. “How much” precision is required of the “how” demand, to satisfy the “what” 
demand, and how much is added to the matrix. Quality characteristics are configurations, dimensions, 
process durability, etc. Processes or technologies that achieve manufacturing quality demands are 
researched, and candidates are selected for least cost and for meeting or maximizing required precision. 
Selections are compared with facility conditions and capabilities. Inspection standards are established, and 
factors that affect control points in manufacturing are identified. 

The assembly process is next developed, and control points for assembly are established similarly 
to the parts process. Resulting quality characteristic precision achievable through selected manufacturing 
techniques are expressed in engineering language and converted into design plans and specifications. Cau- 
tion must be exercised throughout the quality analysis to avoid bottlenecks that limit quality and yield, and 
that increase cost. Engineering bottlenecks arise when quality targets are set at higher levels than previ- 
ously experienced and the levels are difficult to achieve. 

Manufacturing cost reductions may be generally realized through efficient use of materials, new 
processes, flexible production techniques, robots, and others. Trading a little performance for more com- 
mon and reliable production materials may reduce the material cost as well as machining, welding, or 
casting costs. Welds that cannot be inspected must be relocated or eliminated. Reducing the number of 
unique parts reduces cost of assembly, logistics, and learning. Using wider margins assures manufactur- 
ing quality, and may even achieve process control with minimum inspection. Pugh presents many manu- 
facturing design standards for cost reduction. 
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I. Verification 


This design verification application is committed to assuring that all product design details and 
specifications comply with all product requirements developed through systems design analysis phases. 
Designs must be simple to verify in order to avoid acceptance of defective products. The most common 
verification methods are analysis and test. 

The first order of verification is a thorough and refined analysis of a design’s final iteration and 
updated definition of subsystems down to the components level as necessary to confirm targeted per- 
formance. This verification analysis is a continuance of design analysis with focus on final configuration, 
induced environments, interfaces, and refined models. Analysis methodologies encompass statistical and 
probabilistic techniques, and many computational and simulation tools. Critical assumptions are modified 
by timely off-line technology experiments, analytical simulations, and detailed design characteristics and 
data derived from matured interacting elements and components. Quality assurance must consider whether 
the fading quality of a product will continue to function, will affect another product function, or will not 
interfere with component functions as a whole. Reliability of the parts assures reliability of the assembly. 

Tests may be conducted to failure or to no-fail. A no-fail test provides limited experience on the 
article’s safety, regardless of its subsequent successful operations. Incomplete design analyses and sneak 
phenomena are what most premature test failures are about. But other compelling reasons for designing 
tests in this phase are to verify performances and margins, to establish operational characteristics and 
sensitivities, to determine primary failure mode and failure characteristics, to determine design deficien- 
cies, to develop inspection and maintenance procedures, and to fine tune analytical models. 

The performances of components and partial test articles, whose boundaries and operating condi- 
tions are difficult to simulate in a verification test, may also be difficult to interpret and verify. Then the 
operating performance design margins must be increased to allow for all-up test uncertainties. 


J. Operations 

Low-cost, reliable operational characteristics of the launch vehicle and its interface with payloads 
and facilities must be firmly initiated at the earliest concept phase and step, explicitly identified through 
QFD techniques, and incorporated and iterated throughout the systems process. Operational characteristics 
cannot be significantly modified beyond this design phase. 

The industry’s long-term payload processing goals are similar to commercial airline operation stan- 
dards where possible with respect to time, manpower, facilities, documentation, and conflict resolu- 
tions . 23 Payloads should be integrated into standardized containers separate from the vehicle to facilitate 
processing and rapid switching. Standard interfaces and wide center-of-gravity margins should be pro- 
vided to payload containers for a more versatile packaging process, and to increase the reliability to meet a 
launch date. Increasing automation in payload ground handling and checkout should also reduce human 
error and increase delivery reliability. Standard work stations must have data access to weather, ground 
processing status, operations, equipment, and vehicle health to support launch preparations. 

Multipurpose expandable facilities must accommodate a wide range of future vehicles with better 
utilization of less manpower and with shorter schedules. Launch pads must have hold-down engine-shut- 
down capability, be flexible and in sufficient numbers to serve different size vehicles, and assure sched- 
ules and damage recovery. Preparation time should be reduced through more use of automation and elec- 
tronics to improve or eliminate checkout, and to apply multiple testing and continuous health monitoring. 

Vehicles must be designed robustly to increase reliability, operability, and affordability. Simplify- 
ing off-line preparations or eliminating time-consuming critical path tasks, leak checks, and verification. 
Vehicles should use computerized information and communication systems and develop avionics 
enhancement systems to integrate health monitoring, fault identity and isolation, adaptive guidance, 
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flexible mission planning, all weather flying, and multipath redundancy. Operations should be designed to 
select standard flight plans to convert payload properties, vehicle lift capacity, and orbital inclination, to 
program software, autopilot, and trajectory profile. Operations should validate checking the system rather 
than every element procedure. 

Fundamental to the practice of systems design analysis is an understanding of the systems process 
and knowledge of classical modeling techniques including optimization, decision, reliability, economy, 
and management as applied to the total life-cycle of a product. This section assumed these fundamentals 
and suggested many current quality management techniques adaptable to the design process for providing 
quality performance at low cost. 


V. PROBABILISTIC DESIGN, APPROACHES, AND STATUS 


“For other concepts in physics there exist a measuring instrument — a voltmeter for 
electrical potentials, a thermometer for temperatures, and so on. But there is no pitanometer 
for measuring probabilities, and therefore it is by no means obvious how a probability we 
have calculated is to be connected to anything observable,” by Luis de la Pena and Peter 
Hodges. 


A. Background 

The use of probabilistic analysis and design methods in space programs is steadily gaining accep- 
tance within the aerospace community. To further enhance the development and application of probabilistic 
methods, four actions are recommended: (1) the development of theories, codes, and tools to match the 
task areas; (2) an understanding of prior applications/uses of probability and statistics, and data bases; (3) 
the development of data bases, in particular structural failures; and (4) education of engineers and man- 
agers on the merits and basics of probability/reliability methods. The approaches, the status, and the needs 
for these actions were examined 24 in terms of the current limitations of probabilistic engineering methods, 
a basic approach for its application, a discussion of some specific uses, and recommendations of critical 
development areas. 

Probability and statistics have been used extensively on prior and ongoing space programs in spe- 
cific areas, but have not had a universal focus or acceptance. Where used, probabilistic methods have 
contributed significantly to the success of the programs. In recent years, the research focus has been to 
extend these methods for application in design. In fact, NASA design requirements for future space 
vehicles and structures will be specified in reliability terms. However, making the transition from using 
probabilistics and statistics in engineering analysis to the design of structures for reliability is very difficult 
due to the limited structural data bases available in aerospace, and the complexity of the dominant failure 
modes of wear, fatigue, fracture, and buckling. Nevertheless, probabilistic analysis/design is becoming a 
viable approach in all aspects of space programs. Many approaches are currently in use, and development 
is underway on more encompassing techniques such as NESSUS and PDA. Developing strategies for 
advancing the application of probabilistic methods within aerospace provided the impetus for this section. 

Uncertainties in the definition of loads and environments, material properties, geometric variables, 
manufacturing processes, engineering models, analysis tools, etc., and all types of testing including 
development, verification, and certification lead to uncertainties in space vehicle and structural design, and 
ultimately safety. Quantifying and understanding “problem uncertainties” and their influence on design 
variables develops a better engineered, designed, and safer system. Two formats are available for charac- 
terizing design uncertainties: (1) deterministic/safety factor and (2) probabilistic/reliability. The classical 
deterministic analysis approach accounts for design uncertainties in “lump sum” fashion by multiplying the 
maximum expected applied stress (load, environment, etc.), a single value, by a factor of safety. Often, 
design verification is achieved by applying a worst case loading (e.g., a three-sigma load condition 
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multiplied by the safety factor) to the structure and testing to failure. In areas other than structures, the 
same approach can be used. In contrast, the probabilistic format attempts to model individual parameter 
uncertainty by a probability distribution. A test-constructed data base gives the best characterization. If test 
data are not available, then the engineer must make assumptions concerning the parameter distributions. 
Once the distributions are defined, model equations are used to combine the density functions into a cumu- 
lative distribution function of the design variable; for example, applied stress. In this case, the design 
parameter has an uncertainty that is quantified in terms of risk. 

In the case of the design of aerospace structures, it is impossible in the near future to develop an 
aerospace structural design code based solely on the probabilistic format without compromising the struc- 
tural safety of hardware design. This statement is especially true with respect to the currently available 
probabilistic engineering analysis tools and test verification programs. In general, the analytical tools that 
have been developed are difficult to understand and implement into a design procedure; and more impor- 
tantly, the methods have not been test verified or universally accepted by the engineering community. 
Before a probabilistic-based design code or program can be successful, design engineers must develop an 
experience and education base in this field plus accumulate adequate failure data bases. Today, most 
engineering schools do not offer probabilistic-based design courses as part of the curriculum. This does 
not mean, however, that these approaches do not have merit. They serve as excellent tools for assessing 
design concepts using sensitivity analysis and trade studies. Other design disciplines such as avionics have 
substantial data bases, and therefore, are using probabilistics in many ways in the design and verification 
of their hardware. 

True reliability must be demonstrated not simply estimated from an engineering analysis. Until 
failure and failure rate data bases are available from experience, probabilistic methods can best be utilized 
as a design tool to help identify the sensitivities of problem parameters. Furthermore, “demonstrated 
structural reliability” is virtually an impossible task due to the expense and small number of aerospace 
structures that are built. This is not true in avionics. However, it may be feasible to develop a more consis- 
tent structural design code that uses the probabilistic format in combination with the accepted safety factor 
approach to design. The civil engineering profession has successfully used a combined format in the 
development of the LRFD code for steel structures. Developing a similar concept for application within 
aerospace offers a practical area for future research. Before exploring these ideas further, it is prudent to 
look at some areas in addition to avionics that have successfully used probabilistics. Three examples are: 
(1) component development, qualification, and acceptance in shock and vibration; (2) liquid propulsion 
engine vibration and fatigue; and (3) control, dynamic response, and loads. 


B. Previous Applications 

1. Components . All aerospace system components are designed, qualified, and accepted using 
probabilistic approaches. Their design in general is driven by shock and vibration environments that have 
their source in mechanical or acoustical excitations. Shock is also a source of these excitations. Because 
these high frequency environments are nearly impossible to analytically formulate, extensive data bases 
have been developed for both the excitation and the response of basic structural types with different type 
(and size) of components. Input and output responses are put in probabilistic format to serve as a base for 
formulating design, qualification, and acceptance criteria. Using this criteria, shock and vibration tests are 
run on each component. In special cases, all up acoustical tests are run as further verification of the system 
using the probabilistic acoustical environment as input. The shock and vibration discipline has become 
very successful using this approach; however, it has been accomplished through a universal effort to 
establish data bases, special instrumentation, data evaluation, and basing techniques. 

2. Dynamic Engine Data . The space shuttle main engine (SSME) has had an extensive program to 
collect dynamic data (also performance), statisize it, and use it for structural durability, turbomachinery 
health, and maintenance and refurbishment of hardware. This data base is cataloged by engine number, 
parts number, test number (or flight), and test stand. Most firings and flight are over 500-s duration and 
the frequency content of interest ranges up to 3,000 Hz. Figure 14 illustrates the basic approach for the 
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statistical processing of the data. Obviously, this creates a very large data base requirement as well as the 
need for fast processing schemes and user friendly access of the data. Figures 15 through 17 are typical 
plots of data outputs. By combining all test and flight data including test failures, it is possible to 
statistically say what constitutes healthful hardware and is used to determine good hardware during green 
runs (certification) as well as when to change out parts. In addition the engine has been mapped into 
vibration zones and acceleration data acquired for use to determine loads for hardware assessment and 
redesigns. These data can also be used as a starting point for future engine system design. 



Figure 1 4. Statistical processing of high-frequency data. 


20 Radial Acceleration Data of the SSME High Pressure Fuel Pump 
@100% Rated Power Level / Sample Size - 1 21 2 


10 


'jz 


Mean - 3 34 
Std Dev - 1 1 0 
Bin Width -0 50 


Gamma Distribution 


2 3 4 5 

Grms 



Figure 15. Probability density plot. 
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Radial Acceleration Data of the SSME High Pressure Fuel 
Pump @ 100% Rated Power Level / Sample Slze=1212 



Figure 1 6. Cumulative-distribution probability plot. 



Figure 17. Statistical information on engine data. 
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3. Dynamic Responses/Loads . Probabilistic approaches have been used extensively in determina- 
tion of launch vehicle control and dynamic responses and loads. The environments that produce these 
responses exists as natural and induced environments. The aerospace community has developed a natural 
environments data base that is very extensive, including atmospheric density, temperature, winds, solar 
pressure, etc. This statistical data base serves as one distribution into the response analysis. Propulsion 
system characteristics have had the same rigor applied to its thrust, thrust rise rate, oscillations, and thrust 
vector misalignments to serve as inputs for these amazes. The other induced environments such as aero- 
dynamics is based on wind tunnel testing and CFD to determine its characteristics. The resulting analysis 
(loads) can be accomplished using deterministic approaches or probabilistics depending on the needs. Fig- 
ure 1 8 is a flow diagram of how this is accomplished for structural analysis. This data base in conjunction 
with day of launch wind measurements, etc., can be used to ensure a safe launch. 
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Figure 18. Generic flow for structural analysis. 


C. Basic Approach 

The basic probabilistic approach can be summarized as the quantification of all input data, the 
model equations, and the output in a statistical manner. This requires the use of a statistical procedure to 
make the model equations and the input data and to produce a statistical/probabilistic output. These tech- 
niques range from pure Monte Carlo to integral solutions. Figure 19 illustrates this process for structural 
assessment. The left hand side of the figure shows all of the input data indicating some statistical distribu- 
tion of each. The right-hand side illustrates the various capabilities of the structure, while the center shows 
the output of the process again in a statistical sense. Nothing is said of how the input or capability data are 
generated nor how the model equations are solved to get the stress or capabilities distributions. Many 
techniques exist to accomplish this task. The describing equations can be solved using Monte Carlo 
approaches by inputting the parameters as statistical distributions then solving the equations for the various 
combinations selected randomly. The output becomes a probability distribution function or statement. The 
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same equations can be solved using the A-factor approach and the three-sigma limits of each parameter. 
The A-factor approach allows the generation of three-sigma equivalent time response analysis by root sum 
squaring the deltas for each parameter variation. A delta value is defined as the change in the output 
parameter from its nominal due to a three-sigma change in a single input parameter. The root sum squared 
value is used with the individual deltas as a ratio to apply to the model equation coefficients. The final out- 
put is a three-sigma answer. Other techniques exist to deal with these data. Regardless, the objective is to 
rate the probability of an event occurring against its capability to deal with that occurrence. This means 
understanding and predicting the failure modes of capabilities. Given that these can be accomplished, then 
it is straightforward to know how failures occur, etc. Whether one uses Bayesian statistics or many other 
tools, key statements can be made concerning the reliability of the system when the data or good estima- 
tions are available. This same sequence flow takes place for the deterministic assessment; however, no real 
probabilistic or reliability statement can be made concerning the outcome. Ideally, the probabilistic state- 
ment is highly desirable. In practice, this may not be possible; however, it is prudent to utilize as much 
statistical information as possible about the characteristics of the system. This means that in reality a blend 
between the deterministic and the probabilistic be used. 



Figure 19. Probabilistic analysis concept. 

In the past, emphasis has been placed on the tools for solving the model equations to provide a sta- 
tistical answer and ways to estimate the input data in some distribution sense. All of this is needed; how- 
ever, if the complete statistical approach is to become an accepted practice, data must be acquired in terms 
of failures, inputs etc., as has been accomplished in the three examples given previously. In the present, 
use must be made of all the available data in a combined manner as discussed. 

This combined approach uses the statistical data available for the various parameters and combines 
them into a mean and standard deviation, which is used in conjunction with the deterministic safety factor 
concept. The other aspect of the approach uses best estimates of the parameter variations, then conducts 
sensitivity analysis and trades to arrive at concept selections, design, and operational approaches. The 
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assumed parameter distributions can be varied and become part of the sensitivity analysis. This approach 
may be applied to the design of a system for robustness, in which the trade criteria and the product parts 
are part of this trade. Probabilistic/reliability data are key to making the right choices. 

Another area of quality/safety is the FEMA that leans heavily on the probabilistic approach. The 
end assessment is always “How much risk are you taking?” Fundamental to this analysis is the fault tree, 
events tree, or logic tree. 


D. Current Limitations of Probabilistic Methods 

The ultimate goal of probabilistic engineering application is to define accurately the reliability of a 
given design. Although this goal is desirable, it is a very difficult one to achieve for complex structural 
problems; not only in terms of engineering cost and verification, but also in terms of problem understand- 
ing. The major limitations of current probabilistic engineering tools center about this basic goal. Some of 
the more general ones are summarized below. 

1 . Many of the probabilistic analysis tools that have been developed are problem specific and, to 
work a given failure problem, require software modifications. In some cases this type of approach seems 
unavoidable, especially for extremely complex problems that are highly nonlinear and require several math 
models and iterations simply to get one deterministic value. However, the practicing engineer is interested 
primarily in tool application for use in understanding design problems. Tool development may not be his 
specialty. 

2. Generic tools, like NESSUS, do not interface directly with general structural analysis software 
packages such as NASTRAN, ANSYS, etc. Before probabilistic methods will be universally accepted or 
even experimented with in any great detail, they must interact freely with at least one well-developed 
analysis/design tool presently utilized by the practicing engineer. 

3. The probabilistic format requires distribution information for analysis input. In most cases, 
adequate data bases are not available, and the engineer must make assumptions regarding the data. Guide- 
lines for this phase of the process need to be developed. Always, the analysis should be checked with dif- 
ferent inputs to verify the effects of distribution assumptions. 

4. Analogous to structural finite element models (FEM’s), probabilistic math models are only 
approximations to the “real world.” Model inaccuracies and their effects on design must be determined. 
The accuracy of any engineering analysis is only as good as the assumptions that define it. 

5. Computational schemes are grouped into two categories: (1) simulation and (2) approximate 
reliability methods, such as FORM, SORM, AMV, etc., that use FPI techniques. While Monte Carlo 
simulation has fewer assumptions, it requires extensive and expensive computer time for large complex 
models. “Efficient” Monte Carlo simulation methods have been developed, and these along with faster 
computers make simulation a valuable application tool for many simpler problems. Although the approxi- 
mate methods are faster and more efficient with respect to computer usage, they define explicit response 
functions that can be difficult to verify, in terms of accuracy and convergence. Inaccuracies can arise from 
poor approximations to the true response function and nonlinear coordinate transformations. 

Many of the limitations noted are accuracy related. While accuracy is important, it should not be the 
controlling factor limiting the application of probabilistic methods. The methods themselves offer a better 
approach to design, because they require that the engineer understand more details about the problem, and 
even other disciplines. Not only does the probabilistic engineering approach give the designer an idea of 
the risk defined by a given design, it also provides a glance at the parameter design sensitivities. In gen- 
eral, probabilistic methods require more detailed analysis, which ultimately can lead to a more robust 
design. 
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E. Recommendations of Critical Development Areas 


It is very difficult to make the jump from using probability and statistics in engineering analysis to 
predicting the reliability of structures. First, there is a limited structural data base, and to develop failure 
and failure rate data bases for general use in space programs is far too expensive. Second, the dominant 
failure modes of wear, fracture, fatigue, and stability are very complex, leading to model and analysis 
inaccuracies. Therefore, for the near-term, the goal should not be to replace current engineering design 
practices with probabilistic methods. Rather, the goal should be to supplement current safety factor deter- 
ministic approaches with probabilistic methods. For example, performing future designs using both prob- 
abilistic and deterministic approaches in parallel will help to calibrate the probabilistic methods. The 
emphasis should be on the gradual introduction of probabilistic methods that focus on sensitivity analysis 
at the component/failure mode level: (1) to characterize and determine the effects of loads and material 
property uncertainties and (2) to estimate the risk of particular failure modes, such as fatigue and crack 
propagation. This approach is of relevancy to the practicing design engineer and ultimately can lead to a 
more robust design. The greatest strength of the probabilistic design approach is its use in determining the 
sensitivity of life drivers, and the greatest weakness is its inability to demonstrate or verify the reliability 
predictions of expensive aerospace structures. 


VI. THE CONCEPT OF ROBUSTNESS IN DESIGN 


“All design is essentially creative work and the state of mind of the creator is every- 
thing; which is to say that the state of mind of the designer is likewise everything where 
design is concerned.” Unknown source. 

The space shuttle vehicle is one of the great achievements of our time, and yet several aspects of 
the system illustrate the need for robustness: (1) the assembly and processing (including checkout) of the 
vehicle requires extensive touch labor; (2) the launch constraints and problems result in many costly holds, 
not the least of which is the wind loads and dynamic pressure (which has resulted in three launch delays); 
(3) each launch has to be tailored, requiring detailed flight mechanics and loads analysis to accomplish; (4) 
many systems such as the SSME and the orbiter heat protection tiles are designed to the edge of technol- 
ogy requiring frequent maintenance and hardware replacement in order to meet safety requirements. Con- 
sequently, design requirements on new products must circumvent these problems and cost overruns by 
significant order of changes. Business as usual will not meet the goals. New innovative approaches are 
needed in the design of aerospace systems, as suggested in section IV, and emphasis on robustness should 
be a fundamental part of this design process. 

Robustness is not too well understood in what it is, how to achieve it, design for it, and verify it. 
Designing for robustness is further complicated by the many types of space systems that require a diversity 
of materials, manufacturing, assembly, processing, checkout, facilities, operations, etc. In a real sense, 
each type of system has a separate set of measurables and design requirements. Therefore, a specific 
definition of robustness and the necessary design requirements is needed for each program or project. This 
eliminates or restricts the ability to be generic in approach (fig. 20). 

In “Robust Quality,” Taguchi and Clausing assert, “Quality is a virtue of design. The ‘robustness’ 
of products is more a function of good design than of on-line control however stringent the manufacturing 
process. An inherent lack of robustness in a product design is the primary driver of superfluous manufac- 
turing expenses.” This means that to have robustness in a system, we must define: what it is, what are its 
design requirements, what are the achievable characteristics that must satisfy the requirements, and what 
are the measurable parameters that verifies it. 
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Figure 20. Space systems. 


A. General Process 

The approach will form around the items shown in figure 21, which consist of six options and 
their combination for achieving the desired robustness, the concept selection, the trades, and the design, all 
measured against the indexes. Obviously, the measurables related to cost, reliability, and performance are 
not uncorrelated even when they are shown independently. Their correlation or interrelationship must be 
understood as a part of the process. 

The robustness design process starts with the visions of the program, project, or mission and ends 
with successful operations through eight major coherent steps: 

1 . Vision into requirements 

2. Requirements flow 

3 . Robustness definition 

4. Robustness criteria 

5 . Concept selection 
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Figure 2 1 . Robustness design approach. 


6 . Detail design 

7. Manufacturing and verification 

8. Operations. 

These steps are to some extent sequential, yet they are highly interactive considering all areas as the 
tasks proceed. The focus must, therefore, be from a systems viewpoint in order to achieve a balanced 
space vehicle, spacecraft, or space system.'- 4 The flow of these tasks and related subtasks are shown in 
figure 22, and a narrative of each task follows. 

1 • Vision Into Requirements . Robust design starts with a vision that is translated into an initial set 
of requirements that generally includes philosophical and performance goals and guidelines on cost and 
schedule. As noted earlier, space vehicle cost must be drastically reduced. This reduction must be accom- 
plished for the launch vehicle, the payload, and operations. Robustness should reduce cost associated with 
facilities, inspection, rework, maintenance, operations, etc.; but not necessarily significantly reduce the 
development cost, and particularly the up-front cost. 

2. Requirements Row . The top-level philosophy and requirements must flow down to the small- 
est part. 25 This step includes evolving these high-level requirements into many discrete parts. QFD is one 
of the new tools that is very effective in accomplishing this. 
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Figure 22. Robustness design flow chart. 
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3. Robustness Definition . The third step considers the system requirements and flow-down 
requirements and translates them into derived requirements (characteristics) called robustness (system 
focus, stepped convergence). These can be in the form of functional statements of how to, or what to, 
achieve. Determining the characteristics or definition of robustness means that each of these areas must 
have a set of measurables identified so that the level of robustness can be determined. At the top level, this 
can be called the definition of robustness. All areas including design, manufacturing, and facilities must be 
captured in the requirements definition tasks. A part of defining robustness and capturing the characteris- 
tics is a listing and study of prior systems problems that increased cost, delayed operations, etc. This list 
will serve as a basis for describing characteristics, formulating definitions, and developing functional 
statements of how robustness is achieved and the requirements for it. QFD works well in translating cus- 
tomer wants into characteristics, leading to the definition of robustness for the system under consideration. 

4. Robustness Criteria . This next step derives and combines the generic criteria and the require- 
ments (specifications) into a project document. To accomplish this task, documented past experience must 
be brought together with the project specific characteristics in a way that tailors the total into a specific set 
for the project procedures and gives the needed control without introducing excessive cost, etc. This is 
particularly true of the design process as discussed so well by Petroski. 7 These criteria are the key to 
achieving robustness. They must clearly define what it takes to ensure that the design is robust. Pugh calls 
this the product design specifications (PDS). 5 

5. Concept Selection . Next, concept selection is started by listing the functions required to meet 
the vision, requirements, and criteria. Using these functional statements, several viable options are formu- 
lated that can potentially fulfill the visions and meet the requirements. Three tasks are now performed: (1) 
conduct sensitivity analyses that identify the key areas and parameters that are important to achieving 
robustness; (2) conduct trade studies between the potential concepts using the sensitivities and the measur- 
ables; and (3) select a narrow set of concepts, and conduct a more indepth analysis of steps (1) and (2). 
These three tasks are repeated until a single concept is converged upon for design (system focus again). 
Tools available here include, but are not limited to, decision theory, optimization programs, CAD’s, cost 
modeling, and integrated analysis. See Pugh’s concept in “Total Design.” 

6. Detail Design . The detail design is accomplished using the concept selection as a starting point 
and applying concurrent engineering approaches, TQM tools, etc., through sensitivity analysis, trades, 
design, and verification — all against the set of measurables laid out from the requirements or derived dur- 
ing the design process. Both the concept selection and design are evolutionary in nature, requiring several 
iterations. In fact, in discrete areas during design, the originally selected concept has to be iterated, due to 
added information starting the design process over in these areas. Tools available for design are numerous 
and are specific for many disciplines. 

7. Manufacturing and Verification . This step builds and verifies the product, testing many times to 
failure to determine limits for use in operations. Sensitivity testing is also important to determine response 
characteristics. The product is built using a robust manufacturing process ensured by concurrent engineer- 
ing teams up front during concept selection and design. The verification process must determine the good- 
ness of robustness achieved by setting the operational procedures and identifying areas for improvement. 

8. Operations . Operational procedures, constraints, etc., are based on the information generated 
during development, design, and verification analysis and testing. Although operations appear at the end, 
it also must be part and parcel of the requirements, concept selection, and design — a true concurrent 
engineering approach. These procedures, assembly, checkout, launch and flight operations, and health 
monitoring must be designed with the same degree of robustness as applied to the vehicle and payload. 

The design proof task then is how one starts with a system that is decomposed into tiers of com- 
ponents and parts, as required for analyses, and then rolls them back up into the total system, since every- 
thing is interactive. Subsequent subsections will explore these steps as they apply to robustness as one 
means of increasing reliability and reducing cost. 
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B. General Characteristics of Robustness 


Establishing the desired characteristics of robustness is particularly difficult in space system 
design, because the system must be quantified against design criteria and goals. The first avenue open to 
accomplish this is the easiest to state, but is very difficult to quantify. For example, the classical dictionary 
definition reads: “The state of being strong; having been strongly formed or constructed.” “Business 
Week/Quality 1991” defined robust design as a discipline for making designs “production-proof’ by 
building in tolerances for manufacturing variables that are known to be unavoidable. The definition could 
be stated as the insensitivity of the product to requirements, environment, manufacturing, or operational 
variabilities. In space systems where so many requirements are in conflict, this is not a real possibility 
because all designs are a balancing act, a tradeoff. Gordon in “Structures” says it like this: “All structures 
will be broken or destroyed in the end; just as all people will die in the end. It is the purpose of medicine 
and engineering to postpone these occurrences for a decent interval. The question is: what is to be regarded 
as a ‘decent interval’?” 25 

In trying to clarify the two previous statements, the classical and insensitivity, another statement 
can be formulated that reads: “A robust system is one that is designed and verified to have features that 
accommodate variability (three sigma) of parameters that affect performance and margins without 
unacceptable degradation, and achieves the optimum combination of operating costs, reliability, maintain- 
ability, and performance.” This definition treats the total system from start to finish, but still has the diffi- 
culty of determining measurables. The other open definition avenue is a mathematical definition that uses 
deterministic and probabilistic approaches. Here performance indexes must be formulated for each area of 
concern in mathematical terms, then the system verified to those values (fig. 20). The performance index 
definition is stated mathematically as a design that provides a sufficient ratio between “strength” (or capa- 
bility or capacity) and “stress” (or load state environment or operating condition) to accommodate vari- 
ability of the parameters affecting stress and strength without failure inducing overlap. This ratio may then 
be related to cost through a risk factor to complete the definition. For many of the areas, the indicies are 
easy to formulate if treated separately; however, they interact with others, leading to the requirement for a 
higher level index. 

The essence of these preceding statements is required to define robustness. The final result is a 
statement that is a combination of the generic statement and the multitude of mathematical indexes. The 
first can be generic, as stated above. The second is specific for each space system and requires much effort 
to define the sensitivities, conduct the trades, and then quantify the requirements indexes. It is often desir- 
able to modify the statement such that robustness is defined only in terms of one area such as launch 
operations (cost, processing, turnaround, checkout). In this case, each component or subsystem is not 
optimized individually, but only to the extent it affects operations. The indexes are tailored to fit this 
special case. The definition of robustness for a space system is always tailored to fit the needs and 
requirements of that particular product. 


C. Top Level Approaches 

Using the generic definition as a base, the generic makeup, or top level, approach to robustness 
can be formulated. Figure 21 attempts to flow this task. As is shown on the top of the chart, there are 
many elements or ways of achieving robustness. In the case of certain components or subsystems, it is 
possible to design in a measure of robustness using only one element such as structural margins or redun- 
dancy. However, in general, some combination of the ones listed, or others, is required. One of these 
elements can be chosen to be the definition of robustness. In this case, other elements drop out; for 
example, operations such as launch on time. Using this new definition, everything is judged only as it 
affects that special definition. In general, however, to make a total system (such as a launch system) or an 
orbiting system (such as telescope) robust, a combination of all will be required. In complex launch 
systems, spacecrafts, and orbiting instruments, a sensor failure during launch scrubs a mission, while 
failures in operations can lead to mission loss (possible loss of life, if manned). A breakdown in 
manufacturing tolerance may lead to many problems. To have robustness in space systems, the total 
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system must be robust. Each system or subsystems must define what is meant by robustness for that 
system; for example, the launch facility. In all cases regardless of which area or definition is chosen for 
robustness, the sensitivities of the system to its parameter variations against that definition must be 
determined (quantified, if possible) so that robustness is builtin only where needed. The goal for 
robustness by its very nature cuts across many disciplines from flight, fracture, and control, to avionics 
hardware and software, manufacturing, and operations. The basic question is what do you design up front 
to preclude downstream problems? How far do you go? What is the balance? Otherwise the cost and/or 
weight becomes prohibitive or the performance is degraded. 

Designing for robustness proceeds down two legs simultaneously. One is designing the product, 
the other is designing how you make the product (this includes manufacturing and assembly). Operations 
can be separated out of the product design function, creating three legs. Operations is so fundamental a 
part of the product that it must be involved in product design. In other words, the design must be compat- 
ible with the manufacturing, operations, and assembly capacity in order to be robust. It is of little value to 
design a system that manufacturing cannot meet the tolerance requirements, producing yield that is too 
low. Experience in manufacturing of high-performance systems such as the SSME has shown that these 
systems are very sensitive in manufacturing to such things as weld offsets, weld peaking, weld beads, etc. 
producing fatigue or fracture failures and numerous reworks and material review discrepancies. Even with 
these problems, the SSME is an example of the degree of craftsmanship that can be achieved in manufac- 
turing a very complex, high energy density system. The simpler the design, the simpler the manufacturing 
process required. Figure 23 attempts to show this parallel, yet highly interactive, process required to have 
an operational robust system. 



Figure 23. Legs of robust design. 

Robustness in the manufacturing and assembly leg occurs in two ways. First, it must be able to 
achieve the characteristics evolved within acceptable limits. Products are plagued with problems that arise 
because of the lack of manufacturing robustness. Part of the time, this is due to poor communication in 
that the designer did not involve manufacturing up front and ask for more than could be reasonably 
achieved. Then other times, the designer does the design task without consideration for manufacturing 
limitations. This clearly indicates the need for concurrent engineering in both legs. Second, manufacturing 
must be robust in delivering quality robust hardware on time. Robust products depend on both, and there- 
fore, get the same emphasis and focus on the interaction. In the following, it is assumed that this inte- 
gration approach is followed in designing for robustness. 
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D. General Characteristics 


In order to gain insight, it is necessary to first understand the definition, characteristics, and func- 
tions of each proposed way of achieving robustness (fig. 21). With understanding of each potential candi- 
date, the robust system can be achieved using various combinations of these broad areas. 

First, designing for margins (tolerant system) is not straightforward. For example, increasing the 
structural safety factor adds weight that, in turn, can increase the inertial load, not providing added mar- 
gins. Also, if this increased safety factor margin in design is not reduced (limit load safety factor) for 
operations, then no real gain occurs because the system cannot take advantage of this margin except in an 
anomalous situation during operations. Stability margins for dynamic systems including control fall into 
this category because it cannot, by operational design, take advantage of extra margins unless it is speci- 
fied differently for design and operations. The same is true of all other areas such as avionics, software, 
performance reserves, etc. However, extra margins judicially placed early in design can be used as a hedge 
against environment creep, producing, in the end, an adequate system (based on the sensitivities). If this is 
not done, then the environment creep leads to either a redesign or a constrained operational system. One 
way of gaining margins is to take advantage of the inherent nonlinearities, not included in the linear 
design, for operations. This requires more accurate quantification of the response characteristics and is 
therefore more costly. One method for quantification is testing the product to failure; determining the limit 
that can be used to make up robust operational procedures and constraints. 

Second, ideally, one would like to design the system such that it does not respond to variations in 
the parameters. (In the discussion that follows, the use of the word parameters is all-inclusive. It not only 
implies such things as flow, thermal, acoustics, and the like, but also includes manufacturing tolerances, 
processes, flaws, offsets, etc., that affect the robust characteristics under consideration.) In most cases, 
this is not possible; however, when it can be accomplished, the gain is not free. For example, vibration 
isolation of a component (electrical, hydraulic, etc.) renders it insensitive to the vibration, but at the 
introduction of larger deflections from static and quasi-static loads. In other words, vibration absorbers 
can desensitize the component to the vibration by introducing large static deflections; however, complexity 
including new failure modes are added in addition to cost increases. Load relief and ride control add com- 
plexity and new failure modes, as does active thermal control. The same is true for controlling manufactur- 
ing tolerances, etc. However, in many cases this added cost and complexity is more than balanced by the 
gain in robustness. 

Third, control of parameter variations is another design tool for achieving robustness. Many 
examples for this approach exist: active flutter suppression of aircraft wings, pogo suppression, modal 
suppression, rigid-body load relief control, thermal control systems, day of launch I-loads update (real- 
time wind biasing), and SPC in manufacturing, to name a few. These techniques are used extensively and 
are the tools that allow a system to operate safely and meet its performance goals. Another approach to 
controlling the environment is to have a predictive scheme that results in no operational use during times of 
higher-than-predicted acceptable parameter variations. Prelaunch atmospheric wind monitoring for launch 
vehicles is in this category. In this case, the vehicle is not launched into atmospheric disturbances that are 
greater than its capability. Or the I-loads (trajectory shape) is updated to reflect the effects of the wind 
measured 1 or 2 hours prior to launch increasing the margins and allowing a safe launch (day of launch 
I-load update). Controlling the parameter variations is not free, complexity and failure modes are intro- 
duced as well as added cost, assembly, limited operations, etc. In some of these cases, one gives up 
robustness in launch flexibility, introducing operational complexities and increasing cost. 

Fourth, redundancy, particularly on manned systems, is an acceptable way of achieving robust- 
ness. This approach is used extensively in electrical and hydraulic components, windows, fasteners for 
joints, load paths, etc., and such things as dual thermal insulation and debris shields. Again, one must deal 
with complexity, failure modes, cost, and weight. The design in this case must deal with how many layers 
of redundancy is required: fail operations, fail operations fail safe, fail safe. The greater the redundancy 
level, the greater the complexity and cost. 
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Fifth, simplicity in design normally enhances robustness, as well as manufacturing, assembly, 
operations, and response. This design area for robustness is broad in scope, number of elements, load 
paths, geometries, turnings, structural concepts, etc. It also affects redundancy, margins, variations, and 
operability. The use of simplicity in design is a well known approach. Pugh, in “Total Design,” discusses 
it in detail and has formulated some criteria for measuring its achievement. Design simplicity should 
always be a goal. The simpler the design, the easier it is to gain robustness. 

Finally, designing for operability leads to robustness in at least two ways. Complex operational 
procedures cause problems because they open up more paths for errors. The second part of the definition 
of robustness, particularly for space vehicles and spacecraft, deals with launch on time, processing, 
checkout, etc., required for each mission. Ease of operations not only has a direct correlation with sim- 
plicity, but also cost-to- vehicle and payload overruns. As stated earlier, operation efficiency can be used as 
the total definition of robustness. Then the other elements are used as means of achieving this new goal. 

A part of the design for robustness is the use of FMEA as augmentation to the normal design pro- 
cess. 4 Minimum failure modes should be identified for each concept and evaluated in line with the other 
considerations to ensure a better quality of robustness. 


E. Trades 

So far, the six broad areas of designing for “robustness” have been discussed. There are additional 
factors required to deal with these areas in achieving robustness which are applied through engineering, 
trades, sensitivity studies, and design. First, is the criteria that is imposed by the product that provides the 
mantle for the design. The criteria must be carefully tailored to capture the characteristics of robustness 
desired, and must be accomplished by a combined government and contractor team including all pertinent 
disciplines. 8 Second, a key in the robustness trade is the concept selection, materials choice, and fabrica- 
tion requirements approach. These three elements are correlated, presenting options from which the design 
engineer can choose to create robustness (fig. 24). For example, he picks a concept (ring/stringer/skin), 
then chooses between several materials (Al, steel, etc.), and the different fabrication processes (milling, 
welding, riveting, etc.). After repeating for other concepts, a set of trades are conducted to arrive at a con- 
cept selection. He must conduct these trades using the three measurables of performance, cost, and relia- 
bility as the judge or evaluation guide. The cost measurable is very difficult to define. Up-front cost load- 
ing used effectively lowers recurring cost. Which cost is the driver? Concept selection? Design? Recurring 
cost? What is the proper balance between the them? Also, how is the cost of major design problems versus 
indepth up-front preventative design estimated? Proper formulation of the balanced total cost indexes is 
key to good system engineering and robust design. Here, various indexes must be developed for these 
three areas to provide measurables for evaluation. They can be probabilistic or deterministic in nature. 
Developing these measurables is a major task in itself and is fundamental to the process. If robustness for 
any system is to be achieved, these must be developed specifically for the product being designed. 
Intuition, innovation, as well as lessons learned are needed. In most cases, new paradigms must be 
developed. In the early part of the program, much effort must be expended in order to determine the sensi- 
tivities and concept potentials. 

Many approaches exist such as “Total Design” by Pugh, the various Taguchi approaches — QFD, 
concurrent engineering, and probabilistic design. Each must be explored and used to aid in robust design. 
Figure 25 illustrates the process discussed in previous subsections along with their characteristics and a 
partial listing of the available tools. 
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CONCEPTS 



Figure 24. Concept selection. 
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The process is then one of stepped convergence, involving initially several concepts that converge 
through proper trades and design analysis to the concept that can meet the criteria, performance, and reli- 
ability goals. Robustness is only one part of these measurables; many times being in conflict with other 
elements of the requirements. This leads to either a requirement redefinition or decision by the project to 
make certain compromises. All design involves compromises. A design for failure, as is so clearly stated 
by Gordon in “Structures,” is that the success of the design depends on how well this “conflict of expecta- 
tions” is managed and qualified. 

As stated above, figure 25 delineates these steps. This section has dealt with the design for robust- 
ness at a top level. In practice, the process becomes one of applying these principles to components, ele- 
ments, systems, as well as functional areas, each involving very specific trades and criteria (requirements). 
In the end, the total system must be evaluated using these subdivided robust parts to determine if the 
overall robustness goal has been met. 

Robustness is pivotal to space missions design philosophy, which is much more than achieving 
reliable performance at low life-cycle cost. Costly failures during development and operations will be 
greatly reduced if not eliminated. Space systems life may be increased. Operational complexities and con- 
straints and associated costs and delays may be reduced, such as refurbishment, maintenance, assembly, 
processing, and checkout. Robustness, in general, cannot be designed in a global sense. It can and should 
only be used where the biggest payoff occurs, which may be identified through sensitivity analysis and 
trades. It must be incorporated early in the project and pursued throughout its life-cycle. 


VII. DISCIPLINE FUNDAMENTALS 

“To understand what engineering is and what engineers do is to understand how 
failures can happen and how they can contribute more than successes to advance technol- 
ogy,” Henry Petroski. 26 

All designs must be grounded in sound physical principles. As a convenience, these principles are 
divided into categories called disciplines, which promote the development of specialists who penetrate one 
or more of them. It is clear that a design can be no better than the understanding of this knowledge into the 
design. The advantages of this subdividing is obvious; however, there are drawbacks. “Nothing exists in 
isolation. It is always a part of a system, influencing and being influenced by the system and its various 
parts.” While section IV briefly delineated systems interaction, it also illustrated the disciplines interactions 
within interacting systems and implied skills. A partial listing of common skills required by aerospace 
engineers are: 

Induced environments 
Aerodynamics 
Vibration and shock 
Fluids 
Acoustics 
Static 

Heat Transfer 
Dynamic 
Material Sciences 
Avionics 

Natural Environments 
Winds 
Temperature 
Right Mechanics 
Control 
Structures, 
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and specialized disciplines in structural systems designs include: 

Static testing Computational/numerical analyses 

Dynamic testing Breadboarding 

Flow testing Logistics 

Shock, vibration, and acoustic testing Simulations 

Statistics and probabilistics GSE (ground support equipment) 

Welding and brazing Data evaluation 

Casting Data basing 

Software. 

The ability of an organization to acquire and organize the proper balance of the skills required for a 
particular project determines the project’s success. Obviously, there are many other factors in a successful 
program, as discussed elsewhere in this paper. However, none can ever replace the lack of skills required 
in the various disciplines. It behooves an organization to continually train to enhance the needed skills as 
well as search for new blood in the marketplace. 

There is one solace to the analytical disciplines, namely that mathematical techniques are applicable 
to many type disciplines, such as initial and boundary value problems, sensitivity, optimization, etc. It is 
also necessary to point out that all analyses, computations, and testing are models that simulate the physics 
of the problem. The assumptions and compromises inherent in each model determine their accuracy and 
usefulness. Therefore, these assumptions and compromises must be held constantly in the forefront and 
challenged. With time, the tendency is to forget these limitations and target the results as absolutes, or at 
least as a base from which a new system can be up-scaled. This is very dangerous and sometimes leads to 
design failures . 27 

As examples of discipline specialty penetration and the system interactions in the design process 
during the development phases, it should be instructive to discuss the design fundamentals of two very 
complex and progressive disciplines that must be highly honed and intuitively understood to avoid failures; 
structural dynamics and fracture mechanics. Both require many common discipline skills and certain 
specialties listed above. 


A. Structural Dynamics 

The fundamental modes and harmonics of a vibrating string can add quality to our lives. If we 
select certain types of strings in an instrument, we get music (piano, guitar, violin, banjo, etc.). Blending 
instruments together produces more variations and potential. However, not all dynamics are wanted. For 
example, the vibration of an airplane wing moving through air can go unstable and destroy itself. It, there- 
fore, must be contained either actively or passively by design. Couplings that aggravate and make the sys- 
tem response very complex are structure, fluid, aerodynamics, propulsion, control, thermal, acoustics, 
and noise, to name a few. Regardless of sources, the fundamentals are rather simple. For instance, the 
single degree-of-freedom basic equation may be written in the form: 

M(x,t) x + c(x,t)x + k(x,t)x = f (t) ■ 

If this system is linear, then the solution has the two classical parts: (a) transient and (b) steady- 
state and is treated extensively in literature. When the system is nonlinear, the characteristics and physics 
of the problem become very complex. Jumps in the response occur, stability can be limited or divergent, 
etc. Very seldom does any system behave totally like this simple system. If one accounts for all the 
structural dynamic modes, control system modes, fluid modes, and environments, the systems interact and 
tune with many surprising results , 28 such as pogo and flutter. The motion of the total structure is 
composed of a system of substructures that are expressed by the linear matrix differential equation, 
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mx(m+[(nx(t))+[Kix(t)) = (Fit)) . 


Many techniques exist for simplifying this system solution: normal modes, modal coupling, CFD, 
separation of variables, eigenvalues and eigenvectors, etc. The design process requires skills in the use of 
all these techniques and the ability to judge when to use each and what assumptions are valid and applica- 
ble. No system response dynamic analysis is any better than the assumption and the input data. 

What does the simplified equation (single degree-of-freedom) mass spring damper or two degrees- 
of-freedom tell about the fundamentals of dynamics and the approach to understanding and solving 
dynamics issues? First, it provides insight into the general characteristics of dynamic systems. Then it 
points the way delineating many of the tasks required to conduct dynamic analysis. 

1 . Characteristics of Dynamic Systems . Dynamic systems are characterized by the system’s fre- 
quency or frequencies, the system damping (negative or positive), the systems gain, and the external 
forces acting on the system. The frequency or frequencies are determined by the mass (inertia) and the 
restoring forces. 

Damping is determined by forces that are ±90° out of phase with the motion and usually propor- 
tional to the velocity. A positive coefficient on the velocity dampens the motion, while a negative coeffi- 
cient produces a negative damping, increasing the motion (unstable system). It is possible to have 
displacement dependent forces with phase alterations that can also produce positive and negative damping. 
Control-induced forces with special filtering are an example. 29 The forcing function is some externally 
applied force, such as wind gusts on a space vehicle, that excites the dynamic systems. For linear systems 
of the characteristic equation, formed using displace transforms, by setting the forcing function to zero and 
solving for the complex eigenvalue (5 = 8±ico) then the frequency and damping of the system is known. 8 
is the damping coefficient and (O is the frequency in radians or dividing by 2k gives the frequency in cycles 
per second. The response of this system is well known both for initial conditions and for external forcing 
functions. 30 Tuning the forcing function frequency with a system frequency produces large responses due 
to dynamic tuning (resonance) and should be avoided if possible. If a system has many frequencies, par- 
ticularly of its elements, then they can tune up and increase the system response. 

Damping is inherent in all structural systems to some degree as well as most moving parts; how- 
ever, it is usually of low magnitude. Damping can be introduced both passively and actively. Fluid film 
dampers in turbomachinery, visco-elastic materials in structures, hydraulic dampers (shock absorbers, 
etc.), control augmentation, etc. Much work has been done in the work of smart structures that deals with 
these concepts. 

Nonlinear dynamic systems are much harder to analyze and understand. In these systems stable 
and unstable limit cycles occur. Many of these systems exhibit jump phenomena where the response 
amplitude suddenly jumps to a much higher or lower value. 31 

Whether dealing with the linear or nonlinear system, a feel must be developed for dynamic tuning, 
forcing function tuning, damping, and passive and active control of responses. Not only can responses be 
changed by changing the damping, but also by changing the frequencies of the system. History of astro- 
nauts and aeronautics is replete with examples of the exemplification of these principles of dynamics, 
many times with loss of lives and hardware. 32 33 

2. Dynamic Evaluation Tasks . The first tasks dynamicists face are deciding what characteristics of 
the system must be modeled. This implies an understanding of the various potential interacting systems 
such as control, acoustics, structures, fluids, thermal, aeroelasticity, etc. Also, changing boundary condi- 
tions with time must be decided, such as a launch vehicle lift-off that goes from cantilevered to free-free 
boundaries. 
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Second, describing equations must be derived, which are usually ordinary or partial differential 
equations or both. Energy techniques using generalized coordinates are one approach. Many other tech- 
niques exist, which depend on the problem being characterized. 

Third, data from the various disciplines have to be assembled in the right units and formatted to 
characterize the coefficients of the describing equations. This task is extensive, involving much teamwork 
and systems integration. Current automatic networking and data transfer reduces this effort. 

Fourth, tests must be conducted to establish and verify the input data, assumptions, etc., validating 
the developed model. 

Fifth, the describing equations must be solved for the dynamic characteristics. Solving the linear 
characteristic equation for an eigenvalue gives information. Time responses give additional information. 
Sensitivity analysis must be used to identify derivatives and to understand the limits of the system. 

Sixth, the results must be used to either modify the system to get a more desirable response, or to 
verify the system for operations. Operational approaches, procedures, and constraints are then derived 
from this set of data. The implementation of a dynamic discipline into a system design is further illustrated 
in section XII. 


B. Fracture Mechanics 

Aerospace hardware that either has a long-term use (satellites) or several reuses (space 
shuttle/spacelab) must be designed for both fatigue and fracture control. Fatigue is a design for life without 
cracks, while fracture control allows operations with limited crack conditions; and though related, fatigue 
treats crack initiation and fracture treats crack propagation. The matrix on figure 26 compares the low and 
high cycle fatigue, and fracture mechanics applications, advantages, and disadvantages of each discipline, 
and provides good reference for design considerations. 

Because of its recent development and importance noted in the above matrix, a brief overview of 
fracture mechanics in the design process should be instructive . ^ Two of the fracture mechanics 
consequential characteristics are the stress intensity factor and crack growth rate. The stress intensity factor 
is shown graphically on figure 27 as a specimen with a crack under load. Applying linear elasticity 
throughout and working with energy, the stress intensity factor, Kj , results in the in-plane elastic stress 
and displacement fields near the crack tip (measure of loading severity at or near the crack tip). The Kj 
function contains all the effects of loading, geometry, and crack size, all in one parameter. For difficult 
geometries, crack size and loading, Kj_ r , will have a different value, but apart from the value of Kj, the 
stress field will be the same. This solution is general solution for all problems as long as the problem is 
linear with K being the only significant parameter in the crack problem. 

Fracture occurs when the crack-tip stress field exceeds a critical state, Kj > Kq. The critical value 
( Kq ) must be obtained experimentally and is called the toughness of the material. Any time the value K 
equals Kq in any structural component made of this material, the crack-tip stress field will be the same as 
at the time of fracture in the test panel. This result is fortunate in that fracture in all structures of this 
material can be predicted. 

Another characteristic important to understanding cracks is fatigue crack propagation or, as it is 
commonly called, the crack growth rate. Crack growth rate is a materials property determined experimen- 
tally, and is defined as the change in length per load cycle, da/dN. Figure 28 is a typical materials property 
curve for Inconel 715™ for different R ratios (maximum to minimum stress ratio) at room temperature 
plotted versus delta K. These data are then used in fracture analysis to determine the number of loads 
cycles, N, a given initial crack can stand before growing to critical flaw size. 
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Fatigue and Fracture 


Fatigue and fracture mechanics (FM) are engineering disciplines used to assess hardware life. 
Both are related to life but are treated independently. Fatigue actually includes fracture in the 
sense that fracture may be fatigue crack growth. Fatigue deals with that portion of the life that is 
crack initiation and fracture deals with crack propagation. Fatigue is further divided into 
stress-life (S-N) or high cycle fatigue (HCF) and strain-life (e-N) or low cycle fatigue (LCF). 


HCF LCF FM 




Comparison of HCF/LCF and FM Analyses 


HCF 

LCF 

FM 

Applications 

Applications 

Applications 

• Constant amplitude loading with long 

• Where plastic strains are significant 

• “Safe-life" for aerospace and nuclear 

fatigue lines 

(notches or low yield points) 

pressure vessel industries 

• Machine elements such as power 
transmission shafts, value springs, and 
gears 

• High temperature such as gas turbines 

• Variable amplitude load histories 

• Smaller components where initiations is 
of primary concern 

• Components with preexisting flaws, 
particularly castings and welds 

• Components with sharp notches 


Figure 26. Comparison of fatigue and fracture analyses. 
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STRESS INTENSITY FACTOR 



• K| UNIQUELY DEFINES THE NEAR TIP, IN PLANE LINEAR ELASTIC STRESS 

AND DISPLACEMENT FIELDS (MEASURE OF LOADING SEVERITY AT OR NEAR THE 
CRACK TIP) 

• K, = F n (GEOM, g, a) = F <W5ca, IN GENERAL 

Figure 27. Elastic stress intensity factor. 

For linear systems, using the fracture mechanics analysis and the materials properties, several cal- 
culations that produce very critical results can be generated. First, if the stress field is given in conjunction 
with an operational life requirement, then a critical initial flaw size that can exist in the structure may be 
estimated using the known failure critical flaw size. Usually a safety factor is applied to the operational life 
to ensure a margin, which sets the limit that an existing flaw size can initially have and the size that inspec- 
tions must reliably detect. Second, the same calculations can be made for different materials, selecting the 
most appropriate for the conditions. Third, a determination can be made of the stress level reduction 
required to ensure safe lifetime, if the current design cannot meet the flaw size detection limit. Also, main- 
tenance programs, in service inspection programs, as well as hardware retirement programs can be based 
on these data. It is clear from this simple explanation that failure prevention programs can be instituted 
using fracture control. In real life, it is not quite so simple. High-performance systems operate near the 
material capability, and may be nonlinear in nature and sensitive to small changes. These systems require 
more complicated analyses as well as materials testing approaches. The same is true for ductile materials. 
Analog testing, nonlinear R-curves, J-integrals, etc., may be required. Key to any situation is the crack 
detection uncertainty and sensitivities. 

The ability to detect and quantify cracks is the major sensitivity issue. The principle in fracture 
control that tends to govern fracture is the ability to quantify the crack length, depth, shape, position, and 
root radius (acuity), which determines design, use, lifetime, and acceptability. Defining crack uncertainties 
in terms of either allowable stress or fracture life is very important to the design process. Inspection tech- 
niques, such as dye penetrate and x ray, determine crack length well, but are limited in characterizing 
depth. Assuming that the stress is fixed, the relative uncertainty is much higher for small depths and longer 
lives. 
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FATIGUE CRACK PROPAGATION 


a = 0.45-0.55 W 


0.25 W 


1.25 W 


da/dN = C A K 


Spec. 

R-Ratio 

Temp. 

o|A01 

0.1 

21 C (70 F) 

A IB09 

0.1 

22 C (72 F) 

□IA02 

0.7 

22 C (71 F) 

° IB08 

0.7 

22 C (72 F) 


DELTA K (ksi’S/irT.) (1.099 MN/nrT 2 ) 


COMPARISON ON R-RATIO, INCONEL 718 
AT ROOM TEMPERATURE 

Figure 28. Fatigue crack propagation. 












Flaws that are embedded within the structure pose a different problem. Even though the crack size 
is fixed and the structural load carrying area is the same, the cycle life is very sensitive to ligament size 
between the flaw and the surface. Also, accelerated growth can occur due to bending, thermal, corrosion, 
etc. Using x rays, the depth is hard to quantify; however, allowable stress decreases as thickness 
increases. Ultrasonics find defects reliably for fixed size for a given reference standard. Allowable stress is 
basically insensitivity to material thickness. Crack sharpness (defined as crack tip curvature or root radius) 
increases toughness as the radius gets larger. As the radius gets smaller (very sharp crack tip), a point is 
reached where no further decrease in toughness is visible. Allowable stress or part lifetime is very sensi- 
tive to crack size, shape, location, etc. Various generic curves provide, insight into selecting inspection 
techniques and design margins of safety. 


VIII. INTERDISCIPLINARY ANALYSIS 


“Very often there is a conflict between the structural and other functions — the wing 
of a bird or an aircraft is best made thick for strength and thin for performance, a brick will 
be able to carry more load if it is dense but it will be a better thermal insulator if it is 
porous, and so on. Nearly always it is desirable to use as little material as possible both for 
reasons of economy, which apply no less to nature than in human affairs, and also usually 
for functional reasons.” “Invention and Evolution,” Michael French. 

The requirement for interdisciplinary analysis has been illustrated in previous sections. The above 
quote from French leads to the conclusion of requiring interdisciplinary analysis. As was evident in the 
fundamentals of dynamics, a dynamic system cannot be characterized without the interaction of several 
fundamental disciplines, from structures to control, to aeroelasticity, to thermal, to fluids. A discipline 
does not exist alone; therefore this analysis must now be expanded to include cost, operations, and manu- 
facturability. 

Classical interdisciplinary analysis is accomplished by using output data from one discipline as 
input to another discipline analysis. This procedure requires a lot of care and is time-consuming because of 
its sequential nature. A common approach today takes various specialized discipline codes and interactively 
solves the interdisciplinary analysis using a hierarchical code. It works by making initial assumptions then 
interactively moves through codes passing data from one code to the other until the system response has 
been described. With modern high-speed computers, some success has been achieved in this manner. 
Probably for most verification interdisciplinary analysis, this approach is the best due to the details and 
large volumes of data required. If the method is not computationally efficient, it requires strong inter- 
disciplinary communication. 

Pye, in his book, “Nature of Design,” 4 discusses the interdisciplinary design problem and com- 
promises on design. He talks about the sources of problems dealing with the manifestation and transfer of 
energy. Pye states: “Any of these forms of energy is capable of producing changes, changes in things; 
more exactly, redistribution of matter. . . Now whenever a change is made, by the passage of energy, and 
a result is left, this event takes place in a group of things. Things are always together. They do not exist 
separately and they cannot act separately. . . When you put energy into a system, you can never choose 
what kind of changes shall take place and what kind of results shall remain. . . All you can do, and that 
only within limits, is to regulate the amounts of the various changes. This you do by design, which is the 
business of ensuring that at least you get the change you want along with all the others that you do not, 
such as heat, noise, wear, and the rest.” 

Another approach starts by writing the constitutive equations with all the discipline terms included, 
then solving this total describing set of equations. This approach is computer efficient but requires the dis- 
cipline work on the system and not just in their detail special discipline, yet ensuring that each discipline is 
properly accounted for. Several examples exist for this approach. Reference 35 describes how the 
response of an ablative solid rocket motor nozzle can be analyzed including gas dynamics, thermal, and 
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structural. Another example 36 is to have as a direct output from loads analysis, the detailed local loads and 
stresses in the time domain using loads and stress transformation matrices. 


A substantial amount of work on multidisciplinary optimization has been accomplished during the 
last decade or two. Sobieski has spent much of his career developing theories and computer tools for con- 
ducting this multidisciplinary design. He says, “The multidisciplinary design optimization (MDO) is a new 
engineering discipline that enables design of advanced aerospace vehicles, accounting for other conflicting 
influences and requirements of the multitude of engineering disciplines involved .” 37 Sobieski further 
states, “While multidisciplinary integration can be associated with the traditional aerospace disciplines of 
aerodynamics, propulsion, structures, and controls, there are also the life cycle areas of manufacturability, 
supportability, and cost which require integration. After all, it is the balanced design with equal or 
weighted treatment of performance, cost, manufacturability, and supportability that has to be the ultimate 
goal of multidisciplinary integration.” 

Although many excellent papers have been written on the details of accomplishing this task, if the 
interdisciplinary approach to design is to be accepted, then certain fundamental practices must change. The 
most important changes have to occur early in the concept selection phase of design. All aspects of the 
interdisciplinary approach must be present so that the greatest quality leverage is possible and must include 
not only technical engineering disciplines, but cost and schedules. Pugh addresses the importance of con- 
cept selection in “Total Design.” He states that outstanding design engineering can never right the short- 
comings of poor concept selection. The concept selection team must include all disciplines such as cost and 
manufacturing, to work an integrated approach that properly determines the sensitivities and thus evaluates 
and weighs correctly all the trades. Also, it is essential at this time that the users and customers be involved 
to ensure the proper requirements, options, and trades are made. 

All steps of the design process that follow from concept selection must also take this integrated 
approach, usually using concurrent engineering teams. The major problem faced in all the design phases is 
the culture shift that the specialists must make. The specialists must maintain his great depth in the dis- 
cipline and find a way to focus it through the system to look at the system interactions and implications. 
Many times this approach can first be accomplished by simplifying the modeling detail in the areas of con- 
cerns. Final verification probably requires a mixture of the simple and detailed with the emphasis shifting 
to the detailed. 

The discussion above has addressed the need for interdisciplinary analysis, the characteristics, and 
potential approaches. The remaining question is how to implement the process within an organization. Key 
to accomplishing this task is the establishment of an open environment to this new approach, usually 
coming from the leadership. Concurrent engineering teams must then be selected and trained in not only 
the need for interdisciplinary design, but all the tools and techniques. The teams must be an active, learn- 
ing organization as characterized by Senge, in “The Fifth Discipline,” tools must be assembled, networks 
established for data exchange, and the process well established or people will revert back to their discipline 
sandboxes without the desired successes.” 


IX. TESTING 


“In reply to the question. Why don’t you like solid rocket motors? You can’t test 
one before you fly it.” Wemher von Braun. 

Testing is a major tool in the design, verification, and operation of space systems from its smallest 
component to the subsystem and the system. Testing has many roles in the design process, as noted in 
section IV. This section discusses further needs and conditions of testing. Technology developmental 
testing is the source of environmental characterization, materials characterization, structural responses 
(static and dynamic), phenomenon characterization such as aeroelasticity, pogo, smart structures etc. 
Without this exploratory technology and development testing, performance enhancement and quality 
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would be very limited. Quality and acceptance testing plays a major role in ensuring hardware 
(components such as electrical, hydraulic, mechanical) are of the quality to place in service. Nondestruct- 
ive evaluation techniques play a major role in ensuring safe hardware. Verification testing plays a similar 
role and also establishes the margin limits of hardware and software. Usually, in verification testing, some 
of the hardware is carried to failure. As discussed in section IV, testing and failure provide a prime source 
for identification of failure modes and the important parameters inducing failure. Also, there are many 
types of tests with various objectives from screening hardware for safe use to understanding its basic char- 
acteristics. All disciplines incorporate some form of testing. 38 

The importance of the various roles of testing leads to several general principles and procedures 
that are mandatory in order to ensure efficient and accurate testing. The basic principles are discussed in 
the following: 

(a) Model what vou are going to test: test what vou model — Test data in and of itself has no 
meaning. Meaning is established based on a theory by which the data can be interpreted. Modeling the test 
is simply taking a theory and modeling the test to that theory or theories. A structural test is modeled in 
terms of whether the test is static or dynamic. A static test requires a load stress response model, while a 
dynamic test requires a modal model. The model also serves to guide the test. 

Model guidance includes definition and implementation of boundary conditions, instruments, 
environment magnitude and location, and test parameter verification to ensure the results are what is 
needed. Testing often produces unexpected findings. The model serves a point of departure for under- 
standing the deviation or unexpected results. Deriving the model ensures a thorough thought process of the 
physical phenomenon being tested, greatly enhancing understanding. After the test, the model serves as a 
tool for extending predictions to many other conditions important for the design of a quality product. 

(b) Refine the model, and the theory based on the test data — It is mandatory that during and after 
the test the data be correlated with the theory/model, making correction and updating as appropriate. For 
example: structural dynamicists have spent a large effort in developing computational techniques that 
automatically change the model to match the test data. The updated model is invaluable during product 
design and operations for it serves as a foundation for design changes, maintenance, and operational pro- 
cedures, thus increasing the usability of the product. 

(c) Data evaluation and data basing techniques are key to successful testing and program 
integrity — Establishing sound data acquisition and evolution techniques is demanded for successful test- 
ing. The techniques or procedures are rooted in what is to be extracted from the data. If the data are quasi- 
static, large sampling times are permissible. Dynamic data sampling times are much shorter and are deter- 
mined by the frequency contents: up to 30 samples for the highest frequency content of the data. Many 
times real-time displays can be used to reveal the frequency content as well as the quasi-static data and 
these techniques are well documented. 

However, data basing the raw data and how long the data base is archived depends on the pro- 
gram. The archived data base is a fundamental source of information as production and operations prob- 
lems unfold. It also supports establishment of maintenance and operational procedures. For example, data 
basing of turbomachinery vibration data allows characterizing the machine and the elimination of rogue 
hardware during acceptance testing. 

(d) A test is no better than its simulation characteristics — More tests have been compromised by 
improper boundary conditions than for any other reason. If one wants to test a cantilevered beam 
dynamically, the boundary conditions must be firmly fixed. Aerodynamic and fluid flow have the same 
problem where supposedly small irregularities greatly alter the results. The principle is to work the bound- 
ary conditions, test set up, and test control in order to produce a quality and successful test. This requires 
an interaction between the test engineer, test conductor, analytical engineers, etc., in order to ensure ade- 
quacy of the test in terms of the physical phenomenon being explored. 
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(e) Instrument to get the characteristics you are looking for. The same is true of the force app li- 
cation and its control — As discussed previously, instrumentation and its location is done primarily with the 
analytical model. It is also important that developmental hardware be designed for the instrumentation. 
Test forces must be analyzed and well understood in order to not only properly determine the force appli- 
cation points, directions, magnitudes, and phases, but also their behavior to failure. The test depends on 
the use of adequate models as well as knowledge that test environments may have on all associated and 
interacting discipline parameters. How one resolves instrumentation and force application issues deter- 
mines one aspect of the quality of the test. 

(0 Scaling of test hardware relative to full-scale requires a complete understanding of the 
physics of the problem and its limits, or the test data will be misleading or meaningless — Testing in a 
one-g environment requires not only scaling the hardware geometry, but also the manufacturing toler- 
ances. Full-scale manufacturing tolerances coupled with scaled geometry produces large nonlinearities due 
to the increased relative motion in joints, bearings, etc. Aerodynamics and fluid scaling to such things as 
Reynolds numbers are well known, but not always carefully considered. Data interpretation depends 
entirely on the practical knowledge of these dimensional scaling techniques, as well as does the test setup. 
The additional roles of testing are covered in many papers and books dealing with these specialties. How- 
ever, a test matrix is shown on figure 29, which can serve as a starting test design point. The characteris- 
tics of each product will determine the final testing scope using all available information. 

Several techniques have been developed in recent years that significantly broaden the scope and 
efficiency of dynamic testing. Mass additive, a method for deriving constrained or fixed-base modes and 
frequencies from free-free modes of a structure using mass-loaded boundaries, is now operational. Prob- 
lems associated with design and development of test fixtures can be avoided using such an approach. 
Results have shown that mass loading of the boundaries enables local interface modes to be measured 
within the desired frequency bandwidth, thus allowing constrained modes to be derived with considerably 
fewer free-free modes than for unloaded boundaries. 39 

Another method has been developed for deriving constrained modes and frequencies from a 
reduced model based on a subset of free-free modes plus the residual effects of neglected modes. 40 41 The 
method involves a simple modification of the McNeal and Rubin component mode representation to allow 
development of a verified constrained (fixed-base) structural model. Results for two space flight structures 
having translational boundary degrees-of-freedom have shown quick convergence of constrained modes 
using a measurable number of free-free modes plus the boundary portion of the residual flexibility matrix. 
These two methods are an alternate test/analysis method when fixed-base testing proves impractical. 


X. THE ROLES OF PROBLEMS HISTORY 


“A prudent person profits from personal experience, a wise one from the experience 
of others,” Dr. Joseph Collins. 

A key element in understanding how failures can happen is by studying failures experienced in the 
past. Present day engineering is based on analysis and computer augmented design, with greatly reduced 
testing. Testing, nominally, off-nominally, and to failure, in the past provided engineers with the hands-on 
experience of failures and failure analysis and resolution. Most of today’s aerospace engineers must 
acquire failure knowledge from the study of prior problems. 

The approach for applying the history of problems to current projects under development is rather 
straightforward. First, study the documented history of problems, types, solutions, facilities, technology, 
and the resulting knowledge (theory, sources, limits, guidelines, etc.) to understand the physics of the 
problem and the solution. Second, modify results to the project under consideration. A natural outcome of 
this tailoring is the further development and enhancement of models, simulations, test facilities, etc., that 
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Test Area 

Specific Test 

Test Characteristics 

I. 

Aeroelasticity 

La. 

Flutter, vortex shedding, diver- 
gence, buffet 

La. 

Elastic scale model wind tunnel test to 
determine stability boundaries. 



b. 

Aerodynamic 

b. 

Wind tunnel scale model testing to develop 
aerodynamic characteristics and anchor ana- 
lytical/computational models. 



c. 

Acoustic 

c. 

Scale model wind tunnel testing to determine 
aeroacoustic environments. 

II. 

Structural 

Il.a. 

Dynamic 

II. a. 

Structural dynamic test to determine modal 
characteristics and bench mark analytical 
models. 



b. 

Static 

b. 

Strength test to determine design margins 
and failure modes. 



c. 

Vibration 

c. 

Development, qualification, and acceptance 
test of components. 



d. 

Coupon 

d. 

Material characterization for stiffness, 
strength, fatigue, and fracture mechanics. 



e. 

Thermal 

e. 

Thermal vacuum testing for TPS, TCS, heat 
transfer, and acceptance. 



f. 

Proof 

f. 

Structural testing for screening acceptable 
materials flaws. j 

III. 

Fluids 

Ill.a. 

Water 

Ill.a. 

Internal flow testing of propulsion system 
and its components to determine characteris- 
tics and benchmark models. 



b. 

Air 

b. 

Internal flow testing of propulsion system 
and its components to determine characteris- 
tics and benchmark models. 



c. 

Propellants 

c. 

Dynamic propellant sloshing characteristics. 



d. 

Hydroelastic 

d. 

Testing to determine structural fluid 
coupling. 

IV. 

Simulations/ 

Breadboards 

IV. a. 

Avionics 

IV. a. 

Breadboarding of avionics, hydraulic, soft- 
ware to develop and verify system. 



b. 

GN&C 

b. 

Simulation of a space system with GN&C 
to understand sensitivities, design, and verifi- 
cation. 



c. 

Loads/dynamic response 

c. 

Simulations to determine sensitivities/ 
interactions of dynamics and loads. 


Figure 29. Test options. 
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Test Area 

Specific Test 

Test Characteristics 


d. 

Thermal 

d. 

Thermal vacuum testing to verify thermal 
environments/systems. 

V, Qual/ Acceptance 

V.a. 

Vibration 

V.a. 

High frequency shock and vibration testing 
of components to verify lift and screen man- 
ufacturing flaws. 


b. 

Thermal Vacuum 

b. 

Thermal vacuum testing of components to 
environments and responses. 


c. 

Acoustics 

c. 

Acoustical testing of systems to verify 
responses. 


d. 

Proof 

d. 

Static testing to screen flaws and verify use 
life. 

VI. Propulsion 

VI. a. 

Engine Systems 

Vl.a. 

Hot fire testing to verify characteristics and 
margins and sensitivities. 


b. 

Engine Components 

b. 

Ditto 


c. 

Solid Rocket Motors 

c. 

Ditto 


d. 

Vehicle Propulsion Systems 

d. 

Ditto 


e. 

Spacecraft Propulsion Systems 

e. 

Ditto 

VII. Nondestructive 

Evaluation/Testing 

VII. a. 

X ray 

VII. a. 

Evaluation of structures, etc., to determine/ 
screen flaws without damaging system. 


b. 

Dye Penetrant 

b. 

Ditto 


c. 

Sonic/Ultrasonic 

c. 

Ditto 


d. 

Proof 

d. 

Ditto 


Figure 29. Test options (continued). 

are required of good design. Updated models and test facilities are the basis for solving the complex prob- 
lems that developed during the new product’s design and operation. The importance of having this past 
knowledge, and these updated tools and facilities going into a new product design cannot be overstated. 
Numerous examples may be cited where the program would have been canceled had these technologies, 
tools, skills, and facilities not existed. The ATD lox pump for the SSME is a classic example. In this case, 
a deadline was given for the solution of the bearing wear problem or program cancellation. The combined 
skills of users, producers, and universities, assuming a concurrent engineer team, their flow facilities, test 
stand, manufacturing unit, and the newly developed silicon nitride ball bearing technology, were the 
contributing factors that ensured a solution in time to save the program. Current and future programs, 
therefore, depend on past and present problem solving histories in skills, tools, facilities, and enabling 
technologies. These existing problem history sources, knowledge, and design guidelines serve as the 
foundation of future programs. 

Design and operation of space programs are very complex and include space vehicles, spacecraft, 
payloads, manufacturing facilities, and operations facilities that continuously push state-of-the-art technol- 
ogy in engineering, management, and leadership. The systems developed are highly tuned and 
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balanced between competing requirements. This statement is true whether designing a turbopump; balanc 
ing the hydro output (pressure, flow) with vibration, stability, life, weight, and cost; or a launch vehicle’s 
performance versus operational robustness, cost, and schedule. In general, these systems are high-per- 
formance driven, leading to highly tuned systems sensitive to small changes. 

Another role that problem history study plays in a product’s success and survival depends on the 
time phase and innovation eloquently discussed by Utterback in “The Dynamics of Innovation.” 42 There 
are two major observations. The first addresses the shifting of emphasis from the product development 
(technology) to the process (fig. 30). The second deals with the impacts of the invading radically innova- 
tive technologies on the established products (fig. 31). Invading technologies cause the established prod- 
ucts to accomplish bursts of improvements to counteract the invasion. For a period of time this works; 
however, if the invading technologies are strong, they can win out and replace the established product. 
The evolution of the mechanical typewriter to the electric, which was finally replaced by word processors, 
is an example. 


a. Assembled Products 



Product 

From high variety, to dominant design, to incremental innovation on 
standardized products. 

Process 

Manufacturing progress from heavy reliance on skilled labor and general-purpose 
equipment to specialized equipment tended by low-skilled labor 

Organization 

From entrepreneurial organic firm to hierarchical mechanistic firm with defined tasks 
and procedures and few rewards for radical innovation 

Market 

From fragmented and unstable with diverse products and rapid feedback to 
commodity-like with largely undifferentiated products 

Competition 

From many small firms with unique products to an oligopoly of firms with similar products 


Figure 30. The dynamics of innovation. 
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Figure 31. Performance of an established and invading product, burst of improvement in established 

product. 

As figure 31 indicates, in parallel with this product development is the shift from an innovation to a 
process improvement to final standardization. Clearly, as the product life is in its early phase, where tech- 
nology development and implementation is the focus, problem history and grasp is very important as it 
guides the technology development focus, including the determination of the technologies and systems 
needs. The problems experienced drive the technology program. The process of moving a product into an 
established phase requires technology focus, leadership, and managers in order to understand problems, 
their sources, and their system’s impacts. As the product moves into the process controlled phase, the 
emphasis is fine-tuning the technology and processes to achieve better operations, higher reliability, and 
lower cost. This process focus of leadership must be keenly aware of problem prevention. Problem his- 
tory plays a major role also in this process-controlled phase of the product. The transition period between 
technology focus and process focus is also very critical, and it is here that the product makes it or it does 
not. The role of problem history analysis is significant in the transition phase. Comparable conclusions 
were drawn by Handy. 43 

Space exploration is certainly in the transition period, where much of the products technology is at 
the standardized phase, even though space exploration requires even higher performance. The product 
design emphasis is shifting to the process focus with cost, operations, and reliability playing key roles. 
High-performance systems require attention and care or problems erode the gain required for cost and 
operational efficiency. 

Thinking about this evolution and the role problem analysis and history plays, an interrelationship 
emerges, which is required to solve development, operating, and invading technologies threats. As an 
aside, there comes a time when a decision must be made to incorporate the invading technologies or pre- 
pare eventually to go out of business. The salient interrelationships are generally between people 
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development (learning organization), tool development (facilities are included), and technology develop- 
ment. People skills, both technical and leadership, must be constantly developed. Style of organizational 
leadership starts at the top, technical leadership starts at the bottom. First-line supervisors must necessarily 
be style and technical leaders. Style without technology is like an English teacher that writes eloquently but 
has nothing to write about. Most often, this learning is best accomplished by working and developing 
technology options, first during the product emerging phase and then during the sustaining process con- 
trolled phase. It is also clear that if this second leg, technology, is not developed parallel with the product 
development, a time will come when the product will be lost without supporting technological solutions. 
The third interrelationship leg is tool development and maintenance. The tools leg is multifaceted covering 
analysis, testing, information networks, facilities, and management. There are numerous examples in 
space exploration when simultaneous execution of these three legs saved a program (product). 

How does this interrelationship relate to the study of problem history analysis? Problem history 
analysis plays at least two major roles: (1) it serves as source of knowledge that relates in a way no 
academic process can, showing the depth and subtleties of a problem and system interactions and sensi- 
tivities; and (2) it provides the road map and information for developing the technology gap analysis, and 
thus, the priorities and programs that develop the supporting technologies. Problem history analysis can 
help identify the competing technologies and provide the basis for a product shift; however, history has 
shown that the competing technologies usually emerge from the outside. 

Complications also arise because of the funding approach, and many problems are introduced as a 
result. The dominating problem is the stretching of funds and schedules which transfers issues from 
design to operations, greatly increasing operations cost, and decreasing flexibility. In the end, design is 
always a balance between the multitude of conflicting design parameters and requirements. 

Petroski, in “Design Paradigms,” 27 relates that design usually starts to analyze a problem in the 
middle, based on past experiences and scaling forgetting to start at the beginning. He further discusses 
how design changes are made without considering other effects that solving the immediate problem 
creates. Any design change can introduce new failure modes or bring into play latent failure modes. 
Change must be analyzed within the objective of the original design. Senge in his notable work on systems 
data concluded that, “if any small change is made to a system, the whole system must adjust to that 
change.” 44 

As a project unfolds from the concept through development phase, problems develop during the 
design, the development, and the operations of space systems. These problems have both a real-time and 
long-term effect. Many times, in fact most of the time, analysis techniques and tools, testing techniques 
and tools, materials development and characterization and manufacturing techniques and tools are not ade- 
quate to understand and solve the problem. Large efforts are expended to expand these technologies, 
understand the problems, and design fixes so that a successful program occurs. The next program 
assumes this same complexity, building more tools, criteria, and requirements instead of pursuing sim- 
plicity and robustness. This technology should be used to emphasize robustness in future systems. 29 One 
of the most interesting aspects of the evolving culture (still present in aerospace engineering) was the inno- 
vation and creativity engineers brought to the analysis and solution of problems. This was particularly true 
before high-speed, large-capacity computers, when engineers could not brute force the computational 
analysis, but had to rely piece-wise on sound physical principle and innovative ways of coping with the 
problems. The study of problems illuminates this expression of creativity. 

As a result of the high-performance requirements and programmatic constraints, the design, devel- 
opment, and implementation of these requirements has led to many bottlenecks and operations problems in 
aerospace. In addition, operational costs have sky-rocketed as decisions were pushed down stream. Is the 
high cost due to major design process errors or a complex evolving technology? Space exploration by its 
nature involves risks, costs, failures, etc. However, the aerospace industry has matured to the point where 
changes can be implemented to reduce cost and operations (not eliminate), etc. A better design approach 
considers all costs and program phases concurrently in order to reduce total cost. Figures 32 and 33 
illustrate this concept. 
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Design and Verification 

Figure 32. Total optimization, cost, performance, operations, and reliability. 
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Figure 33. Balance between performance and programmatic requirements. 
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The study of problems is one of the sources archiving this approach and success in the future of 
aerospace engineering. Problem history should be a part of every design task, allowing a full consideration 
of the potential failure modes as well as the knowledge of how they occur and the source. The global com- 
petitions together with a more informed customer are bringing to the engineers design scene several past 
and present considerations which must be learned or the competitive edge is lost. As a general statement, 
in the past, the basic focus of the engineer has been on designing for performance: more power, speed, 
etc. Payload-to-orbit has been the driving consideration of launch vehicles. In today’s environment, the 
engineer must still achieve performance, but performance is not enough. Supportability, cost operations, 
and reliability must now be an integral part of the design optimization realm. This added requirement 
greatly complicates the design process and provides a major challenge to engineering. 

If these tasks are to be accomplished, several design process changes must be developed. Cost 
drivers must be formulated, analyzed, and completely understood. The same is true for operations, 
quality, and reliability, and usability. Once these lists have been formulated, characterized, and summa- 
rized, metrics must be developed for measuring them. This task is not simple, since much of the available 
data are either not in the correct form or are not applicable to the design task. With this understanding, 
analytical formulations for the design analysis (multidisciplinary) must be developed so that sensitivity and 
trade studies can be conducted and optimum design concepts selected. 

The complexity of this new approach is clear, for example, cost must include development, verifi- 
cation, manufacturing, maintenance, and operations. The parameters that drive manufacturing cost can 
very well conflict with the drivers of operation costs or can greatly compromise performance. Operations 
of a space system include logistics, assembly, processing, checkout, refurbishment (reuse), facilities, 
support equipment (computers, software, hardware, etc.), and flight operational support. If the system is 
manned, additional design factors must be considered. Again, operational considerations can conflict with 
not only cost considerations but also with performance. 

The section on robustness further illustrates this increased complexity. The many conflicting trades 
and knowledge required to achieve performance-driven design, and the increased dimensionability of the 
problem by adding cost, operations, etc., is obvious. The design process and analysis complexity may 
increase as the square of the number of parameters involved, but the increasing dimensions in design are 
unavoidable for the future of product competition. 


XI. ORGANIZATIONAL FUNDAMENTALS 


“At work, the potter sits before a lump of clay on a wheel. Her mind is on the clay, 
but she is also aware of sitting between her past experiences and her future prospects. She 
knows exactly what has and has not worked for her in the past. She has an intimate 
knowledge of her work, her capabilities, and her markets. As a craftsman, she is working 
in her mind as her hands are working the clay. The product that emerges on the wheel is 
likely to be in the tradition of her past work. But she may break away and embark on a new 
path. Even so, the past is no less present, projecting itself into the future. 

“In my metaphor, managers are craftsmen and strategy is their clay. Like the potter, 
they sit between a past of corporate capabilities and a future of market opportunities. And if 
they are truly craftsmen, they bring to their work and equally intimate knowledge of the 
materials at hand. That is the essence of crafting strategy.” “Mintzberg on Management,” 
by Henry Mintzberg. 

Generally, the design process cannot surpass the quality of the organization in terms of leadership 
and management; therefore, a brief discussion of their fundamentals is here acknowledged. Organizational 
fundamentals have been derived from many years experience in the design process, training sessions, and 
the plethora of literature. The bibliography includes most of those management concepts that have 
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influenced the “how to” of business. The overriding principles of successful design are twofold: 
empowerment and teaming. In reality, it is possible to exercise these principles independently; but prac- 
tically, they play best together as a unit. Also, it is not practical to separate empowerment and teaming 
from leadership and management. The key organizational elements fundamental to successful design are: 
empowerment, teaming, leadership, and management. 


A. Empowerment 

Design success is closely coupled with the degree of empowerment given to each person involved 
in the design tasks. Empowerment is probably not a well understood principle; therefore, it is necessary to 
break it down into subprinciples. The first subprinciple states that the task, requirements, and products 
must be clearly defined, but not to the level that it overly constrains the configuration. This principle 
cannot be overemphasized. Otherwise, creativity and innovation are lost as well as motivation (see sections 
III and IV). The second subprinciple defines empowerment to include all resources necessary to do the 
task, such as people, facilities, dollars, etc. Empowerment without resources is pseudoempowerment. 
Success will be achieved only to the degree that the authority is given in terms of the tasks and the 
resources provided. The third subprinciple indicates that the decision authority must be set at the lowest 
level possible. The person or team responsible for the product makes the decisions; not the managers and 
leaders that they report to. Empowerment without authority is an empty term that breeds poor quality. 


B. Teaming 

It is often said that it is impossible to succeed without teaming, which is very likely a good con- 
clusion. Engineers do not work in isolation. They receive inputs from others in order to correlate tasks, 
and pass outputs to others as a finished product or a required part. With today’s emphasis on teams, from 
skunkworks to ad hoc, some warnings, guidelines, and characteristics are needed. Organizational setup 
does not guarantee success. Teams are merely tools that can enhance the product design. Many companies 
have spent millions of dollars and excessive time creating teams to ensure quality and profits and still 
failed. What causes success or failure of teams is the key question. 

Directly coupled to empowerment is the principle of teaming. The current terminology used is con- 
current engineering teams. The concept is that all the disciplines involved in a product are brought together 
in a team to enhance communications and synergy. Senge, in his book 44 “The Fifth Discipline,” states “the 
tendency of a team is to perform at the level of the weakest member. However, with the proper leadership 
through synergy, a team performs at a level above the stronger members.” There are several fundamentals 
of teaming that are important (fig. 34). The team structure and membership must be geared to the game 
being played (product). For example, golf is an individual game, while football is a very formal game of 
many specialists highly and formally integrated. There is no magic team structure. It cannot increase 
capability, only the opportunity to achieve it. This leads to the second principle that the skills (required), at 
least skill potentials, are selected for the membership. These skills must be continuously trained and 
honed; projects do not provide sufficient time to greatly enhance initial skills. The third main principle is 
that the team generally is no better than its leadership. The word “leadership” is chosen for emphasis 
because proper skills and resources leadership, coupled with empowerment, is more important than 
management. As was discussed under empowerment, objectives and requirements must be clearly defined, 
but not constrictive to creativity and innovation. 


C. Leadership 

“Without vision the people perish.” 45 The first principle of leadership is to develop and infuse 
vision to the lowest level. Infused vision will guide, motivate, and energize an organization, a team, or 
individuals. It is interesting that with vision, many of the management tasks are unnecessary and lead to a 
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Teaming 

1. There is no one team approach. Team structure must match the job that has to be done. 

• Individual performance (Golf) 

• Team of players who perform their parts of the game apart from each other (Baseball) 

• Team of small number of players. Success depends on high degree of interaction (Volleyball) 

• Team of a large number of players who function as members of a unit (Football) 

(very formal in organization and roles). 

2. Teams, team make-up, strategy, leadership, etc. Must be geared to the game (mission). 

Examples: Golf is individualistic, Baseball is combination of individual skill and team, 

Football is strongly a formal team approach. 

3. Teams are product orientated/matrix is discipline orientated. 

4. A team is no better than the skills of the individuals brought to the task. 


5. The tendency of the team to perform at the level of lowest skill of any team members skill; 
however, with the proper leadership a team through synergy can perform at a level higher than 
any one person individual member (“The Fifth Discipline” Senge). 

6. The leader (coach) tries to get consensus; however, in the end he has to make a decision and 
move forward after listening to each team member. 


7. No magic brew in teaming. Does not increase capability, only the opportunity to achieve 
through communication and integration. 

• Cannot accomplish more than skills assigned to it (Human Resources) 

• Except for very long team projects, time does exist to enhance initial skills 

• Skills assigned must match the job 

• The leader assigned is as important as the team members 


- Listener 

- Integrator 

- Mediator 

- Leadership 


- Synthesizer 

- Symbolizes 

- Keep focus 

- Decision-making ability 


8. Clear, Concise, Assignment 

• Mission 

• Purpose 

• Objective 

• Goals 

• Job 

Comments I hear over and over: team does not know what it is to accomplish. Leader does not 
keep us focused. 


9. Must have well defined metrics. 

10. Must have authority and resources to accomplish the job. 


11. All meetings must have agendas, objectives, etc. 


Figure 34. Teaming. 
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Teaming (continued) 

1 2. Operate using 

• WBS 

• Critical path schedule 

• Action plans 

1 3. Team member characteristics 

• Specific discipline skills 

• Analysis and test skills 

• Team player 

- Works well with others - Listener 

- Contributor - Tolerant 

- Communicator - Systems perception 

14. Cross-fertilization of team's members brings insight and enhances communication and 
integration. 

1 5. Provides a strong sense of identity with a product and sense of accomplishment when successful. 
Have withdrawals if forced to leave or disband team. 


16. Concerns 

• Tendency to become self-perpetuating 

• Hidden Agendas 

• Discipline skills deteriorate (become generalists) 


Figure 34. Teaming (continued). 

large reduction in constraints. Another leadership function is providing empowerment, authority, and 
resources. Provisions for continuous training are a part of this function. Many excellent books on leader- 
ship are referenced. 46-59 


XII. SPECIAL TOOLS 


Scattered throughout the previous sections are statements on various tools of the trade of engineer- 
ing. It seemed important to discuss to some degree the types of tools available and some listing of potential 
tools for use. This is not an exclusive list. Tools are also under constant development; therefore, each 
engineer must find what the latest list is and choose his tools accordingly. 

Engineering tasks have always required special tools, whether they be signs in the shop, slide 
rules, computers, or graphics. In our age of information explosion and implosion, the use of tools is even 
more important and is not only hardware, but analytical, computational, etc. Large amounts of information 
require that it be collapsed or reduced to symbols or top-level parameters for digestion, understanding, and 
communication. This process, however, means that we are giving up information (details into top-level 
symbols or parameters) in order to efficiently engineer projects. Two fundamentals in the use of tools are 
necessary for success: (1) the engineer must be well grounded in the fundamentals of his or her discipline 
and he or she must continually think in terms of the physics of the problem (computers can never replace 
this), and (2) he or she must thoroughly understand a wide scope of tools, physical, analytical, and 
computational, available for his use. This means a constant testing of the underlying assumptions. 
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constraints, etc., of the tools in order not to apply the tools to areas where they are not valid. This is a 
major problem of young engineers — blindly accepting a tool and the results it gives. This principle applies 
to analysis, test, manufacturing, and computation. With these two principles as a foundation, tools are one 
key to successful engineering. 

Tools fall into several categories, some of which are: 

(1) Computational 

(2) Testing 

(3) Graphics 

(4) Mathematical 

(5) Data evaluation/processing 

(6) Management 

(7) Ground support equipment (GSE) 

(8) Manufacturing. 

Figure 35 is a matrix that lists representative tools, their characteristics, and applications. The 
reader should be aware that this is only a representative list at a given point in time and must be made 
complete and current by the practicing engineer. Many sources are available for doing this and include 
textbooks, reference books, technical publications by the technical societies, etc. The point is tools are 
necessary for the accurate and efficient design and operation of any space system. Shock and Vibration 
Programs reference 60 is an excellent example. 


Cateqory/Tool 

ApDlication 

• CAD/CAM/CAE 

Computer-aided design, manufacturing, engineering that is integrated to 
allow electronic data transfer and a direct link between engineering and 
manufacturing. 

-IDEAS 


-Pro Engineering 

- Intergraph EMS 

- Auto CAD 


• Response 

Codes for writing the equations and solving for the dynamic/transient 
response of spacecraft, launch vehicles, and structural systems. 

- MATLAB 
-TREE TOPS 
- NASTRAN 


• Control System Synthesis 

Codes to determine control system logic, stability, and response. 

- Nyquist 

- Root Locus 
-TREE TOPS 



Figure 35. Tools with application. 
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■ Robotics 

- Manufacturing 

- Deployment 

- Retrieval 

- Handling 

Random Vibration 


The use of control logic coupled with manipulator arms, etc., to accomplish 
various manufacturing, retrieval, and deployment. 


Transformation of time domain dynamic data into frequency domain data. 


- Data Evaluation (Frequency Electronic storage of data by serial number, etc., of components, sub- 


transformation) 
- Data Basing 

■ Networking 

Virtual Reality 

Rotordynamics 

-TRAP 


- ROTDYN 


- CRITSPD 

- INCYL 

- ITURB 

1 Artificial Intelligence 
1 Design of Experiments (DOE) 


• Quality Function Deployment 
(QFD) 

• Probabilistics 

- NESSUS 

• Computer Graphics 


Acoustics 


Propellant Dynamics 
- LOMAN 


- SLOSH-5 


- Hydroelastic Slosh 


systems, etc., for each of recovery and evaluation. 

Electronic transfer of engineering data, information, and communications. 
The use of computers, etc., to simulate physical phenomena. 


Turbomachinery, rotordynamics, analysis, package (code) that performs 
nonlinear response, critical frequencies, etc., of rotating systems. 

Nonsynchronous, flexible rotor dynamics program to determine stability and 
orbit response of a flexible rotor. 

Code to determine critical speeds of rotors/turbomachinery. 

Turbulent-laminar hybrid cylindrical bearing characteristics. 

Steady-state bearing seal systems characteristics. 

Use of computer logic, etc., to provide intelligence to systems. 

A method for determining the optimum sets of parameters for efficient 
testing and analysis. 

Method for requirements flow down. 


Codes to perform probabilistic design/analysis for systems. 


Codes for accomplishing both static and animation graphics of physical 
systems. 

Codes for calculating acoustical modes, frequencies, and pressures. 


Linear solution of sloshing providing equivalent mass, spring model. 
Finite element approach to fluid sloshing. 

Mode shape and frequencies of coupled fluid/structures tank. 
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- LO BOND 

- LAMPS 

- LHMAC2 
Fracture Control 

- NASCRC 

- FLAW GRO 

- NDE 

-X-Ray 

- Ultrasonic 

- Dye Penetrants 

■ Computational Mechanics 
- NASTRAN 
- ANSYS 
- STARDYNE 

- EAL 

- ABACUS 

- PATRAN 


-SINDA 


- TRASYS 

- TSS 
-CMA 

■ Computational Fluid Dynamics (CFD) 

- GRIDGEN, GENIE++, EAGLEVIEW, 
CAGI, GEN2D, HYPGEN, SAFE 


Low-g sloshing mode shapes and frequencies. 

Low-g large amplitude sloshing of a liquid. 

Description of large amplitude sloshing of a liquid in a tank. 

Critical flaw size. 

Critical flaw size and growth. 

Nondestructive crack/flaw detection. 


Finite element structural analysis. 

Finite element structural analysis, thermal analysis. 
Finite element structural analysis. 

Finite element structural analysis. 

Finite element structural analysis. 

Grid generator for structural, fluid, and thermal analysis. 
Thermal analysis. 

Thermal analysis. 

Thermal analysis. 

Nozzle ablation. 


Grid generation codes. 


OVERFLOW, GASP, FDNS, ROTOR Flow solvers. 


- PLOT3D, FAST 

- RAMP, RAMP2, MOC, SPF/2, 
PLIMP/LSD 

- REMCAR, GASRAD, SEPRAD, 
RAVFAC 

- BLIMPK88, LANMIN, DATCOM, 
STATE 

- FMAERO, BURNETT, DSMCPLUME 

-OISPS, CPCMS, VAEPPS, 
PCBOOM3, FSI, ATMS 


Post processing/graphics code. 
Plume flow fields. 

Plume radiation. 

Aeroheating. 

Orbital aerodynamics. 

Fluid dynamic data analysis. 


Figure 35. Tools with application (continued). 
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XIII. THE DESIGN CYCLE 


“It is important for all of us to understand how engineers choose and plan the 
changes they make, because engineers have an effect upon the kind of world we live in out 
of all proportion to their numbers.” “Engineering and the Mind’s Eye,” by Eugene S. 
Ferguson. 


Implementation of the systems design phases discussed in section IV involves many different pro- 
cesses. The structural system of a launch vehicle is chosen as an example to illustrate the process of the 
design cycle. Details vary for the design of various type systems, and this example should contain the 
essential process principles for most design forum. Assessing final structural design assumptions, input 
data, and structural margins is one of the major tasks in space exploration projects. The end result is a 
statement of performance margins as safety factors on ultimate and yield stresses, fracture limits and con- 
trol, fatigue lifetime, reuse criteria, stability factors, deflections and clearances, operational criteria and 
procedures, handling criteria, etc. The process is normally called a load cycle and is time and labor inten- 
sive, very complex, and involves much more than structural considerations. The design cycle starts with 
mission and flight performance analyses as discussed in section IV and moves through the vehicle concept 
options and selection, which involve many trades and sensitivity studies. The design process then contin- 
ues with control studies, dynamic response analysis, loads determination, heat transfer analysis, etc. The 
structural analysis phase of the design begins once the correct inputs are given to determine the design 
parameters, the design configuration, and the resulting verified margins. Each of these tasks requires def- 
inition of environments for each mission phase as well as all expected changes and parameter variations 
including manufacturing, assembly, operations, etc. The goodness of the structural design is, therefore, 
contingent on the adequacy of each part and step of the total process. Most tools and techniques to imple- 
ment the design process are now standard and available. Invariably, however, unique phenomena emerge 
that must be resolved by the organizational readiness discussed in section XI. 

The design process is essentially the same whether one is dealing with a launch vehicle, or its 
components, facilities, payload, satellites, orbiting platforms, etc. In general, design requires massive 
information flow, which is one key to project success. Flowing results and iterative changes from one 
discipline to another and across interfaces is very important. Interface control document (ICD), environ- 
ment definition, constraints, and the like are all a part of this design process. Other factors are leadership 
and management of the process, adequate analysis and testing tools, data basing, communications, people 
skills, and training. 

Although not shown explicitly on many flow charts of load cycles, material characterization is 
another key to design success. Materials characterization is usually stated in some statistical manner such 
as A-base. The data take several forms depending on the discipline task that uses it. Most structural analy- 
ses require the quantification of element stiffness such as axial, torsional, bending, etc. Hence, the static 
strength properties of yield and ultimate are required. Special analysis such as fatigue, fracture mechanics, 
and stability requires additional materials characterization. Also, structural goodness depends on the update 
and accuracy of these data. Materials characterization applies not only to standardized data bases, but to the 
uniquely generated data bases for specific design problems in progress. Successful design requires the 
structural engineers and the materials engineers and specialists to be in constant contact and have a work- 
ing knowledge of each others discipline. 


A. General or Overall Approach 

The approach chosen for structural design and verification must be comprehensive, consistent, and 
focused. Therefore, it is necessary that common philosophies, requirements, criteria, environment data 
base, models, analysis approaches, verification requirements, configurations, and missions be employed 
by all disciplines, vehicle systems, and system elements to ensure design maturity, compatible risk 
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assessment, and design margins. The total process must be planned, implemented, and managed, starting 
with mission requirements and moving through disciplines performance analyses and verifications. This 
process then sets many of the operational procedures and constraints. Figure 36 outlines the total process. 
Notice that operational drivers and requirements must be initially identified, with evolution occurring 
through refinement of the design process (see feedback loop). Cost is a fundamental control in the 
process. 



Figure 36. Load cycle. 

Figure 37 attempts to tie all the different environments, analysis, testing, design verification, and 
operations tasks together, and figure 38 shows the makeup of a typical set of environments. 

Figure 39 portrays a launch vehicle design matrix of configuration inputs with systems and opera- 
tional requirement and constraints. Their interactions identify evolving tasks and associated disciplines 
leading to quantified design products and verification requirements. 

Up front, the basic problem facing design and verification tasks should be clearly stated. The 
problem: all analyses and tests are limited simulations that attempt to predict trends and approximate physi- 
cal validity. In other words, models are models, not exact representations of physical law, but are mathe- 
matical assumptions of these laws. The number and kind of assumptions determine the degree of replica- 
tion. Hardware testing in general does not duplicate flight experience, because it is usually a ground test of 
partial systems and assumed environments. Test constraints, etc., set the limitations as assumptions do in 
analysis. How these pieces are put together determines the validity of the design. This problem is apparent 
for all the different pieces of the structural process, which starts with the configuration. 

1 _ Statistical Implications . One important piece to the puzzle present in all of the parts of the pro- 
cess is the statistical significance of the data. Uncertainties in the definition of loads and environments, 
materials properties, geometric variables, manufacturing processes, engineering models, analysis tools, 
and so on, and all types of testing including development and verification and certification lead to uncer- 
tainties in space vehicle and structural design, and ultimately safety. Quantifying and understanding 
“problem uncertainties” and their influence of design variables through sensitivity analysis develop a better 
engineered, designed, and safer system. Two formats available for characterizing design uncertainties are 
deterministic and probabilistic addressed in section V. Because of its historical influence, simplicity, 
generality, and compatible data base availability, deterministic is the prevailing method used in most 

semistatic structures. 
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Figure 37. Structural design process parameters. 




Runway 

and 

Taxiway 

Roughness 



X 







X 



Noise 





X 

X 

X 

X 

X 

X 



Meteoroid* 







X 






Electro 

Radiation 







X 






Albedo 







X 






Solar 

Thermal 

Radiation 




X 

X 


X 






o 

n 

<L> ,t5 
-C U 
Cl -r 

on £3 

O U 
c 

< 53 


X 

X 

X 

X 

X 


X 

X 

X 



o 2 

*s § 

Js c 
cu *S 

C/1 C 

O 3 
£ c 
*2 o 
< U 

X 

X 

X 

X 





X 

X 

X 


C/5 

3 

W) 

C 

3 

Uh 


X 











-3 

i 

3 

X 

X 

X 

X 

X 




X 

X 


X 

Salt 

Air 


X 

X 

X 





X 

X 


X 

Sand 

and 

Dust 

X 

X 

X 

X 


X 



X 




Hail 


X 

X 






X 

X 



c 

'3 

od 


X 

X 

X 

X 

X 


X 

X 

X 


X 

Wind 

and 

Gusts 


X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

Atmospheric 

Properties 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 


Environment 
Life Phase 

Manufacturing 

Storage 

Transportation 
and Ground 
Handling 

Prelaunch 

Launch 

Ascent 

Space 

I Entry (Winged) 

Atmospheric 

Flight 

Si 

Landing and 

Horizontal 

Takeoff 

Entry 

(Non-Winged) 

Recovery/ 

Towback 


69 


Figure 38. Structural life environments. 
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Figure 39. Vehicle design matrix. 
















2. Configuration Definition . The configuration must be defined very specifically for the various 
analysis and development testing to end up with the required structural design and verification analyses 
and test. The definition starts with the line drawings, defining all dimensions and interfaces, and identify- 
ing the various major subsystems and elements. Mass characteristics by elements, subsystems, and sys- 
tems are first stated as mass, inertia, and center of gravity, followed by mass distributions that are required 
for dynamics and control analyses. Propulsive characteristics must be included along with basic mission 
objectives. Concurrent with this configuration definition is the establishment of the general philosophy, 
guidelines, and criteria. 61 It must be emphasized that all these definitions and characteristics be consistent 
across all analyses that feed data to the final structural analysis, which must be ensured through manage- 
ment prescribed procedures. 

3 . Philosophy. Criteria. Ground Rules, and Guidelines . Another part of the design process noted 
in figure 39 matrix is the definition of the underlying philosophy, criteria, standards, and guidelines placed 
on the project. Criteria, standards, and guidelines set the design and the verification requirements. They, in 
general, are legally binding and are therefore a fundamental focus of verification. Criteria not satisfied 
must be wavered or the product is redesigned to meet the requirements. Legal requirements must be 
simple, unambiguous, concise, and direct, providing order to the engineering process; but not over- 
powering to where they stifle creativity and remove responsibility, as discussed in sections II and III. 
Determining the design and operational philosophy is the last guiding decision to be made. Many times it is 
dictated by top management. This is not the best approach; philosophy should be originated by a team 
representing all disciplines affected by the choice (section XI). 

4. Mission Requirements and Analysis . The first part of mission analysis is to determine the basic 
requirements. Payloads to orbit requirements include inclination, orbit position, launch vehicle and launch 
site (section IV). For a satellite, requirements include orbit, orientation, pointing, and stability. The 
mission analysis necessary for the load cycle moves from requirements to define mission sequence of 
events, timelines, to abort considerations, etc. This task should not precede the configuration definition. In 
reality, the two move concurrently, along with preliminary performance analysis and iterations. Once the 
real load cycle starts, an iteration has been partially accomplished. However, the resulting loads basically 
influence the sequence of events and timelines, and must be fed back as a part of the fine-tuning process. 
The completeness of these definitions is important to the process cycle. In fact, some would put trans- 
portation, assembly definitions, etc., as a part of this process task. Regardless, missions requirements 
must be specifically defined in order to identify all subsequent analyses required. 

5. Environments Definition . Definition and verification of the environments required for all the 
various analyses and test tasks are very critical to structural reliability. Not only must the mean be deter- 
mined, but also its variations. In general, a statistical representation is preferred. The environments must 
be established in a consistent data base; however, each analysis task usually requires a different formula- 
tion. For example, rigid-body vehicle control analysis for ascent flight only needs total aerodynamic 
coefficients of normal forces, drag, and moments, while an elastic-body loads analysis must also include 
aerodynamic distributions along the vehicle body points correlated or consistent with the rigid-body data. 

Environments are classified as natural and induced. The natural environments are: atmospheric 
winds, temperatures, atmospheric density, solar pressures, magnetic fields, chemical, and gravitational 
(figs. 37 and 38). Induced environments are broader in scope and can be complex nonlinear functions of 
the system operating conditions and responses. Typical examples of external flow are aerodynamics, 
aeroacoustics, propulsion, acoustics, overpressure, thrust, flaunting pressures, drag, noise, electro- 
magnetic, solar pressure, aeroheating, and plume heating. Internal flow environments include acoustics, 
pressures, turbulence, and temperature. Other induced environments are pyroshock, vibration, control 
forces, and propulsive steady state, flaunting, and acoustics forces (see figs. 37 and 38 for more details). 

To the degree that these environments can be understood and quantified, is to a large measure the 
degree that structural integrity can be determined. With the complex shapes and high-performance 
requirement of modern space systems, the problem of accurately determining environments must be 
balanced with the best in human skills, design tools, and as testing techniques. The design engineer must 
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apply well-formulated theories in computational fluid, mechanics, and statistical tools in conjunction with 
test. Demming emphasizes the importance of theory in data interpretation. The approach generally is to 
anchor all analysis tools through benchmarking against special test and known data (fig. 40). 



Figure 40. Process. 

6. Fli ght Mechanics and Performance . Outputs of the flight mechanics and performance analysis 
required for design and verification occur in several trajectory sets that are generated to create a three-sigma 
condition for each unique discipline design. For example, a three-sigma trajectory for a launch vehicle with 
thermal environments is different from a three-sigma trajectory set with loads. This analysis task then has 
two basic functions; the first of which is to determine the three-sigma performance characteristics and the 
performance reserves and residuals that size the tankage and set certain parts of the mission sequence. The 
second function generates the specialized three-sigma reference trajectories required for all the design and 
verification tasks, including but not limited to loads, thermal, control, aborts, maneuvers, aeroelastic, run 
and docking, orbit transfer, reentry, and landing. 

Between the mission analysis and the flight or orbital mechanics, the baseline trajectory, timelines, 
sequence of events, etc., are determined. They provide the framework for all design and verification 
analyses (fig. 41). As a part of this process, analyses that use and follow performance analysis must feed 
back into the performance discipline all constraints that influence its optimization. For example, to meet the 
space shuttle q (aerodynamic pressure) constraint, two options are available, SSME throttling and trajec- 
tory lofting. SSME throttling is more optimum in that there is only 25-lb payload loss for each 1 lb/ft 2 
reduction in q, whereas lofting has the penalty of 150- to 200-lb payload loss per 1 lb/ft 2 q reduction. The 
qa and qp constraints can be met by a and P shaping, wind biasing, load relief, and operational day of 
launch constraints. 

All of these constraints cost the system. For example, load relief costs performance and introduces 
a high thermal load when the path error caused by this load relief is corrected (fig. 42). In all cases, it is a 
tuning between conflicting requirements, demanding open communication and continuous feedback in 
order to achieve the best system. Obviously, cost, reliability, and schedules greatly influence these deci- 
sions. Therefore, good understanding and communications must exist between all design and analysis 
groups to ensure completeness and compatibility. This is true whether dealing with a launch vehicle, a 
satellite, space station, etc. The analyses and trades may be different, but the process is basically the same. 
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Figure 41 . Typical trajectory profiles. 
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Figure 42. Aerodynamic heating constraints. 
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7 • .Control and Dynamics Analysis. Control and dynamics analysis is fundamental to the loads 
cycle, which generally sets the boundaries for the induced environments. In fact, the control forces them- 
selves are part and parcel of these induced environments. There are two fundamental ways that these 
effects can be determined first. The control discipline in the natural design process determines the control 
design, including the control system logic and all its parameter variations that satisfy both stability and 
response considerations. These data logic and parameter variations are passed on to the loads analysts 
along with the reference trajectories (fig. 43), who then run the response and loads analyses. Then, control 
response analysis can be run in a manner that develops the critical induced environment envelope parame- 
ters that are used by the loads analysis team to generate loads. For example, control response analysis can 
generate compatible sets of three-sigma control forces and response parameters such as angle of attack, 
gimbal angles, rigid body rotation, and translations, including rates and accelerations and impact forces 
such as docking. Loads can be computed directly from these data sets (figs. 44-46). 



Figure 43. Pitch control block diagram. 
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Figure 44. Comparison of Mach number between kinematics and dynamics trajectories. 
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Figure 45. Comparison of dynamic pressure between kinematics and dynamics trajectories. 



Figure 46. No wind angle of attack. 


For example, a space shuttle critical parameter is aerodynamics, and qa is plotted versus qfi pro- 
viding a simplified set of three-sigma design conditions (fig. 47). These squatcheloids must be generated 
for each Mach number providing an aerodynamic design envelope as a function of time (fig. 45). Trim 
gimbal angles (control forces) and lateral and rotational accelerations envelopes must be provided and be 
compatible with the squatchloids. Both approaches have been used successfully. The choice depends on 
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the project (vehicle, satellite, etc.) and its characteristics. Many times one approach could be used for early 
design phases, then later design phases would require another. Regardless of the approach chosen, 
dynamics and control analysis is a key element of the load cycle and must be conducted for all interacting 
events, such as lift-off, max q, separation, rendezvous and docking, pointing, and orbital maneuvers. 



Figure 47. Flight envelope by use of squatcheloid. 

In addition to all three analysis tasks, control functions may be used to reduce responses and loads 
to meet margins and verification requirements, and to avoid structural redesign of otherwise submarginal 
design. In fact, a design can be optimized through the use of control logic such as load relief, modal sup- 
pression, auto land, and ride control. This approach, in general, saves weight, but always introduces addi- 
tional failure modes that must be considered as part of the loads cycle. 

The structural analysis proceeds with the detailed loads and heat transfer analysis, which become 
inputs for the stress analysis. The resulting stress analysis determines the inputs for the strength and 
durability analysis. The verification process is based on the resulting preliminary margins. These analysis 
tasks are treated in detail in later sections of this report. 

8 . Leadership. Management, and Integration . A critical and dynamic function in the structures 
design process is the leadership, management, and integration. One of the problems experienced on NASA 
programs has been a breakdown in the systems or integration activities. There has been a tendency toward 
a linear sequential dump-it-over-the-fence approach that discourages interdisciplinary communication. This 
results in missed interactions, creating design bottlenecks that can result in performance, cost, and sched- 
ule impacts. Key to solving the systems and integration issues are leadership and management. The impor- 
tance of leadership cannot be overemphasized because it sets the mission, the goals, and, therefore, the 
culture of the groups and the process. Leadership has a major impact on the loads cycle success. Just as 
important is the management approach used. Many different tools and approaches have been successful. 
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Each project has to determine the ones that best fit that project. Some factors are the project scope and size; 
number of elements, subsystems, and components involved; number of sizes of organizational elements 
(contractors, government, etc.); and project complexity (both technology and organization). Regardless of 
the approaches, some of the essential elements are (1) critical path schedules that show all the interaction 
flow, (2) cost control, and (3) technical integrity and recovery. Section XI discusses this role in more 
detail. 


The space shuttle used a fairly complex government-contractors organization to ensure integration 
(fig. 48). At the top level, a program change board approved all changes that affected cost, schedule, and 
performance. Also, there was a hierarchy of groups that formulated the recommended changes and carried 
out the integration function. The over-arching group was the systems integration review (SIR) that had 
two supporting integration working groups: (1) propulsion (PSIG) and (2) ascent flight (AFSIG). A series 
of technical panels supported these two groups with technical issues and trades. The two working groups 
became a forum for reviews and a mechanism for formulating recommendations to the SIR and finally to 
the program requirements control board (PRCB). The two working groups also ensured that consistent 
criteria was applied in all tasks. 
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Figure 48. Shuttle level II management flow. 

The Hubble space telescope used a series of technical panels that were integrated by the project and 
chief engineer’s offices. Also, during the 2 years prior to launch, ad hoc government teams of both project 
and engineering were located at both contractors’ plants. The SSME extensively used ad hoc teams com- 
posed of government and contractors to solve technical problems and integration management through the 
chief engineer’s and project offices. 
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B. Structural Tasks 


Structural tasks include model development, development, and verification testing; heat transfer 
(thermal) analysis; and loads analysis. The basic concept and philosophy of this part of the loads cycle are 
shown in figure 49. The process starts with each element and its subelements providing the structural 
models and all pertinent parametric data (example, solid rocket booster (SRB) thrust, thrust rise rate, pres- 
sure) to the integration contractor for the system loads analysis. These models must be compatible with all 
other element models and with the final element stress analysis models, including matching FEM nodes. 
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Figure 49. Structural analysis. 

The system integration approach, parameter variations, statistical criteria, and verification required 
are worked through the integration groups. Using these criteria, loads analysis for each design condition 
(parameter combinations with natural environments) is conducted and loads outputted. These analyses are 
conducted in a statistical manner such that the resulting responses (loads, etc.) are at an approximate three- 
sigma probability level of occurrence when varying all system parameters and environment values within 
the expected range. Included are all vehicle parameters and natural environment, such as wind speed, wind 
shears, and wind gust. Individual parameter variations will not necessarily be at the three-sigma level, but 
the resulting variations produce a three-sigma combined statistical response. For example, a three-sigma 
response would not have individual three-sigma wind speed, shear, and gust in combination, but would be 
a three-sigma response using the individual probabilities (distribution) of these wind parameters. This 
response can be accomplished in the response analysis using such techniques as Monte Carlo, or on the 
environment side, by creating a combined three-sigma wind environment. Loads output are bending 
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moments [M x (t), M y (t), Af -(/)], shears [(S x (t), S y (t), S z {t)], and interface forces where applicable, 
Pi(x, y, z, t). Vehicle stations for these outputs are determined by the element needs and integration 
requirements. 

Using the appropriate sets of operational interface and external loads on each element, the structural 
design parameters and margins are determined. Phase IV starts with a more detailed model (than the one 
used in system loads analysis) in conjunction with the interface capability plus the interface forces tor con- 
ducting subelement responses. The subelement response that follows provides more detailed structural 
capability by using a still higher fidelity model. In addition, this subelement analysis provides the interface 
forces for a detailed linear and nonlinear analysis of any substructure requiring special considerations or 
having low margins. This analysis is to be accomplished using very fine grained models in conjunction 
with special codes and analysis techniques. The heat transfer and structural model developments are a big 
part of these structural tasks. The same points made previously in terms of modal or simulation compati- 
bility and consistency apply to these areas also; erroneous test boundary conditions produce erroneous 
data. It should be clear from this general approach discussion that models, response data, input data, etc., 
must be consistent and compatible to ensure proper results. The following subsections discuss the details 
of each of the steps and provide some typical examples. 

It should be pointed out that computational and testing techniques have become very sophisticated 
and often are blind to the user. Without supplementary guides, the structural phenomenon will not be 
understood, resulting in erroneous applications or interpretations leading to serious design faults. Two 
commonly used references are (1) to conduct simplified hand analyses including free body diagrams, 
flows, schematics, etc., to ensure that the phenomenon is clearly understood; and (2) to conduct sensitivity 
studies to the level that all key parameters interactions are noted and appropriately resolved. Computer 
models, analyses, etc., are models and only as good as the assumptions used. These guides may also 
serve more comprehensive studies. 

1 . Systems Loads Analysis . Systems external loads analysis approaches are treated extensively in 
literature. 62 66 Some of the referenced key elements that constitute the basic approach to calculating sys- 
tems loads are herein highlighted. The systems loads analysis of each element must use models of proper 
detail and characteristics to predict systems interaction, and to account for accurate loads distribution and 
all element-to-element forces. Therefore, all element-to-element interface structures and backup structures 
are correctly accounted for in the system analysis to ensure that these forces are output properly. Figure 50 
shows the flow of the interaction studies. Included in this figure, along with the models, are the additional 
interactions between environments, performance, loads, and verification. The solid arrows show the inter- 
active analysis phase. The open arrows identify the verification. Load analysis interaction is shown con- 
ceptually in figure 5 1 , using the data flow occurrence for the different phases of the margins assessment. 
This chart details the loads and stress interdisciplinary analysis given in figure 50. Notice, the strong inter- 
active loops depicted by the double lines. Also, the major outputs are ultimate and yield margins of safety, 
fracture mechanics and nondestructive investigation (ND1), fatigue (lifetime), stability, and responses. 

The approach used to generate space shuttle loads is illustrated using the example of the external 
loads analysis process as an example of loads analysis for the lift-off regime. The first step (fig. 51) 
utilizes test-verified dynamic models of each element (SRB, external tank (ET), SSME, orbiter, payload, 
and mobile launch platform (MLP)). These models are coupled together using proper interface models in 
conjunction with either substructuring or modal controlling techniques. This step produces an overall 
vehicle dynamic model containing up to 300 modes with frequencies through 50 Hz. Step 2 takes this 
complicated dynamic model and descriptions of all known forces and formulates a set of describing differ- 
ential equations. When these equations are integrated time-wise, they will describe the dynamic character- 
istics of any point on the shuttle structure. Various methods can be used to develop this set of math equa- 
tions; however, the Lagrange method is usually used by selecting sets of generalized coordinates. The 
procedure is to define the kinetic and potential energy functions, dissipation functions, and, through virtual 
work, the generalized forces. Integration of the resulting equations, using either digital or hybrid 


79 



EARLY DESK3N SENSITIVITY INVESTIGATIONS 


•NATURAL ENV. 
■EXTERNAL/INTERNAL 
INDUCED ENV. 
•EXTERNAL FORCES 
-THRUST 
-AERODYNAMICS 
-CONTROL 
-CONSTRAINTS 


SYSTEMS 


RESPONSE OF SYSTEM 

PERFORMANCE 



C0NFK3UFLAT10NDESIGN 
CONCEPTS DETAIL 
DESGN 


•DESIGN LOADS CRITERIA 
•LOADS CYCLES 
•CONSTRAINTS 
•CONTROL 

MASS, GEOMETRY, SIZING 
THRUST 


•ETC. 


it 


MATH MODEL 
DEVELOPMENT & 
ITERATION 


WJT 

VERIFICATION 


MATH MOOEL 
VERIFICATION 


SYSTEM RESPONSE 
VERIFICATION 


•GROUND TEST 
•DIRECT MEASUREMENT 
•ELEMENT DEV/PERF 
TESTS 

•MOTOR FIRINGS 


•COMPONENT & 
SUBSYSTEMS TEST 
•ELEMENT MODAL 
SURVEYS 

•ALL UP SYSTEM MODAL 
SURVEYS 
•FLIGHT TEST 


•SYSTEMS LEVEL TESTS 
-FRF -MPT 
-FLIGHT TEST 
-DEVELOPMENT FLIGHTS 
•SYSTEM LEVEL REVIEWS 
-PDR -FRR’S 
-CDR -AUDITS 
-OCR 


Figure 50. Loads analysis flow. 


Test Requirements | 


Design 

Criteria 


I Margins 
lof Safety 


Critical Flow Lifetime/ 
Definition & Predictions/ 
Insjjt. Req'ts Evaluations 


Fracture 
• Mechanics 


| Analysis U Analysis 


Design Concepts 


Structure 

Models 


Test Requirements 


/Tapability' 
V Definition,/ 


Evaluation^ 
v Detail J 


v\ 


Stress Analysis 


jLTM & Algorithm 


Model Reduction 


Define 

Complex Loads Analysis 
Loads 
Spectra 


Environments 

•Engine acousticVovcrpn'ssurc 
• Acrodynam its 

•Prclau nch/ascc nt/ land ing constrain is 
•On-orbit disturbancc/jittcr 
•Ruid flow 
•Control 

•Docking, etc. (impact) 

•Static loads 
•Ac roc last icily 
•Materials properties 
•Thermal 


Model Integration 


[System Model(s)J 


(External Loads I 


I Internal Loads 


Vibroacoustics . 

^ Test 

Criteria & Loads 

Requirements 


Minimum 
Iterative Cycle 
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computers, produces the responses and external loads (step 3). Since generalized forces are not precisely 
known (i.e., only known to a test-verified statistical level), a discrete loads case will not describe the 
design loads. Step 4 consists of running many cases of loads determined by taking different combinations 
of the possible variations in generalized forces. Different parts of the structure will show higher loads for 
different parameter combinations. Therefore, to maximize loads for all critical structures requires a 
multitude of cases run. Figure 52 shows one parameter set varied for developing lift-off loads. Presently, 
it takes 27 cases to develop theoretical load sets for all pertinent shuttle structures. Loads analysis 
progresses through this process by varying the vehicle and environmental parameters to obtain these 27 
sets of three-sigma loads response. 
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Figure 52. Parameter variations for loads analysis. 
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Figure 52. Parameter variations for loads analysis (continued). 

As discussed in the section XIII. A, three-sigma loads response is a vehicle structural load having a 
three-sigma probability of occurrence under all possible natural and induced environment combinations; 
not worse-on-worse combinations of three-sigma levels of each parameter. A single discrete loads case is 
not possible because different wind directions and other parameters maximize the load for different parts of 
the vehicle structure. In order to facilitate determination of these different cases, load and stress indicators 
of critical structural areas are utilized. Load indicators are algorithms that relate external loads to structural 
capability. Load and stress indicators should be developed early in a program and updated as required in 
order to simplify analysis and outputs. A typical indicator is shown on figure 53. These loads and stress 
indicators and/or transformation can be analytically determined during the normal flow of building 
dynamic and stress models or by curve fitting stress analysis results as a function of key parameters. 


Load Indicator Equation L3-42 
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Figure 53. ET load indicator, hydrogen barrel panel. 
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Using these indicators and other design criteria, design loads cases are run for each of the shuttle 
operational flight events as was discussed for lift-off. These shuttle operational events include: 

1 . Transportation 

2 . Assembly 

3 . On-pad (including vertical assembly building-to-pad move) 

4. Lift-off (SSME ignition through lift-off transient) 

5. Max Q 

6. High g 

7 . Reentry (SRB and orbiter) 

8 . Water impact (SRB) 

9. Towing (SRB) 

10. Landing (orbiter and payloads) 

1 1 . SRB separation 

12. ET separation 

13. Aborts 

14. Pointing 

15. Man motion 

16. Docking 

17. Breaking 

18. Planet landing 

19. Maneuvers. 

Important parameters to be varied in order to provide the sets of the three-sigma loads are: 

1 . Control (gimbal angle, gimbal rates, vehicle acceleration, vehicle rates, angle of attack, etc.) 

2. Propulsion (thrust, thrust rise rate, pressure, etc.) 

3 . Winds (speed, shear, gusts, and direction) 

4 . Pyro (thermal) 

5 . Trajectories (load relief, launch azimuth, orbit, payload) 

6. Inertia 


83 



7. Mass 


8. Configuration (geometric offsets, shapes, etc.) 

9. Aerodynamics 

10. Payload variations 

1 1 . Mission variations. 

Satellites are an example of other design projects that are even more complex. Satellites must sur- 
vive the environments of a launch system such as space the shuttle and other mission critical events: 

1 . Docking 

2. Rendezvous 

3 . Retrieval 

4 . Maneuvers 

5 . Maintenance 

6. Pointing control 

7. Orbital plane changes. 

Also all satellites are exposed to a different set of environments such as solar heating, solar pressure, 
gravity gradients, and magnetic field. 

The process, the concerns, the approaches, etc., are in the same category as those discussed under 
space shuttle loads. Additional techniques and tools that are available and have been used successfully 
include frequency responses, probabilistic techniques, acceleration factors, Miles relationship, data banks, 
etc. Modem high-speed computers have opened the choices even more. All techniques and tools should be 
considered and weighted in terms of accuracy, efficiency, etc. The final choice depends on the pro- 
ject/system under development. 


(a) Shock and Vibration Loads Combination . One aspect of a general loads cycle analysis that is 
not usually discussed is vibration loads combinations. All parts of a structure that are elastically mounted 
(including most hardware) with a mass under 500 lb have a fundamental part of their loads generated by 
vibration. These substructures also influence the structure to which they are mounted. In general, the 
vibration frequency spectrum of interest is from 50 to 2,000 Hz. The sources of these vibrations are aero- 
acoustics, mechanical (fans, turbopumps, valves), pyro, and propulsion (main and auxiliary). 

Analysis approaches are straightforward and empirical, although some advances in analytical tech- 
niques have been made, such as statistical energy methods. The first analysis step is the determination of 
an external forcing function, if applicable. The second step determines the vibration criteria, which is 
defined in at least four ways. (1) Accelerometers are strategically placed to map the vibration charac- 
teristics. With enough samples, a statistical data base is developed that serves as the basis to define the 
vibration criteria. This approach has been very effectively applied to liquid propulsion engines where an 
extensive ground test development and verification hot-fire program exists. Also, launch vehicles that have 
flown many times have provided the same data base. (2) The second approach relies on existing data bases 
of vibration criteria and their corresponding acoustical environments. By mass scaling between the data 
base component and the new hardware component, and scaling the forcing function, a new vibration cri- 
teria is developed 67 (fig. 54). (3) Another way is to analytically predict vibration using the predicted 
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forcing function. In general, the scaling approach or the direct measurement approach is used. (4) Finally 
actual flight or development hardware can be acoustically tested to the expected acoustical spectrum. 
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Figure 54. Scaled vibration spectrum with criteria. 
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Vibration criteria is used for two basic purposes: (1) qualification, acceptance, and development 
testing of components, and (2) generation of loads to be combined with the quasi-steady loads previously 
discussed. The subject of load combinations is strongly debated. Low-frequency loads can be easily time 
phased and combined. However, the high-frequency loads can have several cycles during the peak of the 
quasi-static loads, hence the two peaks must be added. The peak vibration load is calculated using Miles 
relationship which assumes that the component is in resonance with the criteria. This technique requires 
knowing the frequency and damping of the component the vibration is driving. Once these parameters 
have been determined, the frequency and amplitude of the vibration criteria are used to calculate the load. 
This load is basically the “ q ” (resonance damping gain factor) times the criteria amplitude. The method for 
combining the various axes of vibration loads with quasi-static loads is still under debate, no universal 
agreement has been reached. Regardless of the approaches, determination of the high-frequency loads and 
their combination with the quasi-static loads are a fundamental part of the loads cycle. 

(b) Verification . It is mandatory that for each parameter used a verified statistical distribution, 
including the three-sigma level, be determined and input into the analysis. Any appropriate parameter 
variation, sensitivity analysis, statistical combination such as Monte Carlo, root sum squaring, etc., can be 
used to generate the loads data. 

The structural models must be verified by dynamic and static tests preferably of full-scale hard- 
ware. With proper attention, scale testing is acceptable. All testing must be preceded by a pretest analysis, 
guiding the test conditions, instrumentation location, and test approaches. A posttest model update is 
required, based on the correlation of model and test data, to provide a basis for assessing changes, manu- 
facturing discrepancies, etc., and, particularly, to predict with confidence criteria for operational conditions 
not directly verified by test. 

Verification of input parameters is accomplished through tests of various types, such as wind 
tunnel, propulsion system firing, etc. Pretest analyses are required for guiding test definition, instrumenta- 
tion, and the like, with post-test updates providing the final data sets. The space shuttle configuration was 
verified in this manner, and figure 55 is a partial listing of some of the key verification tests. 


• \ -Scale ground vibration testing (QSGVT) 

- The individual element modal vibration test of the empty SRB's, full SRB's, 
external tank (ET), and orbiter (ORB) have been completed. The first mated 
test with the ET and the orbiter started June 15, 1977 and was completed 
July 31, 1977. The ORB/ET/SRB liftoff condition tests started August 1, 1977 
and were completed September 21, 1977. All -scale modal vibration testing 
was completed by December 1977. Influence coefficient tests (I/C) were 
completed on the empty SRB and ET. The I/C tests on the full or liftoff condition 
SRB was conduct in January and February 1978. 


• Mated vertical ground vibration test (MVGVT) 

- MVGVT test using the existing Saturn dynamic facility systems and components 
started in May 1978 and was completed November 1978. 


Figure 55. Typical integrated ground tests. 
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l est and Location 

Configuration 

Propose 

• Umbilical systems verification (LETF) 
(K SC) 

Flight-to-ground umbilicals with associated 
flight vehicle skin panels and ground systems 
(i.e., swing arms, tail service masts) 

Verify ground-to-flight interfaces in 
performance and compatibility areas prior to 
MOF 

• Structural test article (ET) 
(MSFC) 

LO 2 tank, LH 2 tank, and inter tank 

Verify the strength integrity of the primary 
load carrying structure 

• Structural static/fatigue 
(orbiter) 

(Palmdale) 

Airframe structure including all primary and 
selected secondary structure, generally no 
systems 

Verify structural integrity for: limit and 
ultimate loads and 160-mission life X scatter 
factor of 4 

• Static structural test 
(SRB) 

(MSFC) 

SRB short-stack configuration, structurally 
flight type vehicle with four center motor 
segments eliminated 

Verify structural integrity for critical design 
limit and ultimate loads and the norma) 
service life 

• FWD RCS status firings 
(WSTF) 

Shall consist of structure and components 
functionally configured to represent the flight 
article 

Demonstrate the RCS performance 


Test and Location 

Configuration 

Propose 

• MPTA 
(NSTL) 

Three main engines + flight-weight external 
tank + flight-weight aft fuselage, interface 
section and a boilerplate mid/fwd fuselage 
truss structure 

Verify MPS performance and compatibility 
with interfacing elements and subsystem 

• OMS/RCS static firings 
(WSTF) 

Consisted of flight-weight primary and 
secondary structures, flight-weight qualifiable 
components functionally configured to 
represent the flight article 

Demonstrate OMS, RCS performance 

• ECLSS 
(JSC) 

Boilerplate test article, complete ECLSS, 
partial avionics, crew equipment, and airlock 

Verify ECLSS integrated ops and perform 
man-rating of ECLSS for FVF (8 lb/in 2 ), 
verify airlock performance 

• Flight readiness firing 
(KSC) 

First shuttle vehicle 
OV-102 

Flight external tank 
Flight SRB's 

Perform unmanned SSME firing at 
completion of the first wet countdown 
demonstration test, final verification of 
flight and ground systems prior to FMOF, 
performed one time only 


Figure 55. Typical integrated ground tests (continued). 


All significant design changes are verified and loads analyses reconducted. The final verification of 
any system is accomplished through development flights or during operations. Critical design areas are 
highly instrumented, for loads and environment correlations to load predictions and design loads. Six of 
the first seven shuttle flights carried verification instrumentation. 
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The final verification of an ET strut load was obtained by correlating actual flight predicted time 
responses to the measured flight data. Figure 56 is the comparison of strut load for STS-5 of predicted 
versus measured loads for the lift-off event. Predicted design loads are higher than flight measured loads 
but contain the same trends and frequency content indicating good analytical approaches. A similar com- 
parison was completed for the max q flight event with excellent agreement. 

ANALYTIC AND FLIGHT-MEASURED 
ATTACH LOADS FOR STS-5 


LIMIT DESIGN LOADS: + 230 klb 



01 23 456789 10 

TIME FROM SSME START (s) 

Figure 56. ET strut load predicted to flight lift-off. 

(3) External Loads Output . The three-sigma load sets are obtained by the techniques just described. 
The loads are output in format at locations required by the elements for margin assessment. In general, 
these loads are output as a time-consistent set of shear, moments, and interface loads at each prescribed 
station. 


Figure 57 is a typical example of this type of loads output for shuttle during SSME buildup 
through the lift-off transient. Depicted in the figure center is the shuttle vehicle. On the left is one example 
of the many input forces used concurrently; other typical forces are listed. On the right are the resulting 
time responses of the SRB at the ET attach ring station. Included are the three strut forces (interface 
forces), the three shear forces, and the three moments. Loads outputs of this form should be defined for 
any vehicle station. 
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Space Shuttle Pre-Liftoff and Liftoff Transient 
Loads Analysis 
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Figure 57. Shuttle lift-off transient loads. 

The large capacity of modem computers allows optimization of computer outputs providing several 
options. Classically, the time-consistent dynamic loads are treated as quasi-static loads that are added to the 
static loads generated in an independent stress analysis. If the dynamic model is compatible with the stress 
model (compatible node points, etc.), these two steps can be treated simultaneously. Using stress or loads 
transformations, the output of the loads analysis can drive the transformations, producing time-consistent 


stresses. This approach saves modeling time, requires less loads cases to produce the three-sigma condi- 
tions, and opens the door to a consistent Monte Carlo stress analysis. The Monte Carlo approach produces 
a more realistic representation of all design parameters than the other approaches used, such as A-factor. 
As programs mature, load indicator definitions can be used in the same manner. 

The peak values (time consistent sets) for all stations should be combined to provide running load 
distributions for static analysis. There must be as many sets of time-consistent shear and moment load dis- 
tributions as there are load sets and flight event analyses. Time consistency must be maintained as a 
general rule. Output of loads as described in this subsection becomes the input for the element dynamics 
and structural assessment analysis (internal loads). The final structural margins are a direct result of the 
characteristics and accuracy of these loads, procedures, approaches, tools, etc. Structural margins must be 
established and controlled early in a design program to ensure detail characterization. 

2. Heat Transfer . Heat transfer, as well as all the thermal analysis outputs, is important to at least 
three design areas: (1) structural deflections and stress, (2) thermal protection design and verification, and 
(3) thermal control including life support systems. Structural design and margins are mainly concerned 
with areas (1) and (2). Also, the heat transfer models must be compatible with the stress models. Heat 
transfer and the resulting deflection are generally performed using codes such as SIND A, PATRAN, and 
NASTRAN. Additional codes exist for special cases such as ablative nozzle analysis. The thermal analy- 
sis, heat transfer, and the thermal protection system (TPS) are all very important in structural design and 
margins. All the points previously made concerning models, assumptions etc., are applicable. 

The thermal analysis (heat transfer) serves several functions. First and foremost, it is a design 
function that provides the thermal control system or TPS required to maintain structural integrity. Exces- 
sive heat lowers the materials properties and, if high enough, erode the material. Second, thermal gradients 
build in residual stress and use up part of the structural stress margins. Third, thermal gradients heating up 
and cooling down structures produce unwanted deflections. These deflections can be very detrimental to 
pointing control systems as well as minimizing design hardware clearances. For example, the cryogenic 
propellant affects the ET and the shuttle system significantly and was a major design consideration. Before 
loading the propellant, the tank is at ambient temperature. When fully loaded, the tank shrinks, which 
introduces radial loads between the two SRB’s (held down to the pad with large bolts that are pyro- 
severed at SRB ignition) and the tank through the struts. The tank also shrinks longitudinally. To handle 
the tank shrinkage effects, the struts between the tank and SRB’s at ambient temperature are designed to be 
7° of 90° so that at full propellant load they are perpendicular to the SRB/ET. Also, the struts are pre- 
tensioned resulting in minimizing the cryo shrinkage loads. 

Figure 58 illustrates the basic thermal control and thermal analysis task flow. As was the case with 
design loads, thermal models must be developed and verified and the design concept selected. Thermal 
analysis, thermal design, and thermal environments definition require testing, simulations, and materials 
characterization. For example, except for the active control concepts, the basic TPS design analyses are 
similar; requiring special definitions of the environments and loads that maximize these inputs for thermal 
protection design and for generation of thermally induced design stresses. Two types of testing are 
required: developmental and verification. The developmental testing defines parametric data as ablation 
rates and thermal responses, and bench marks the thermal model. The verification testing involves com- 
bined environments testing, including thermal vacuum, as well as subsystem and witness panel testing. 
The output defines the operational procedures, constraints and margins. 
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SUPPORTING TASKS 

•RESEARCH & TECHNOLOGY DEVELOPMENT 
•COMPUTER CODE DEVELOPMENT 

•PROGRAM REVIEWS, SEB'S, PANELS/WORKING GROUPS 


Figure 58. Thermal control task flow. 

3 Developmental Testing . Developmental testing covers all aspects of the structural tasks from 
environmental determination to structural dynamics, statics, vibration, thermal/TPS, environments, acous- 
tics propulsion, and control. Full scale as well as scale model testing is appropriate. In all cases, the test 
hardware must accurately depict all features important to the test goal. Test boundary conditions, instru- 
mentation, excitation, data collection, and data banking are fundamental concerns. In addition, develop- 
ment testing parameter sensitivities must be explored as well as potential nonlinear phenomena. 

4 Element Structural Analysis . The next phase for determining structural margins is accom- 
plished using the time consistent and running loads generated by the system as discussed previously. The 
first step in this phase is the generation of compatible and detailed dynamic and stress models, the models 
derived for the system analysis are not applicable. Areas requiring more detailed modeling are localized 
regions of known stress discontinuities, potential nonlinearities, etc. The same consideration applies to 
stress and loads transformations. Several choices have to be made in determining the details of these 
models, including element mesh and sizes, element type, symmetry, nodes, degrees-of-freedom, local 
geometries, welds, and connectors. Based on these and other considerations, models are developed and 
verified using standard check criteria, available test data, or by special test. 

The next step uses the system analysis outputs, forces and moment interface time histories, or the 
running loads as forcing functions and applies them to the model to determine basic detailed element 
response Describing equations, etc., are derived as discussed under systems loads and solved in a compa- 
rable manner. Output of these analyses are either dynamic responses or stresses. This level of analysis 
accomplishes several important tasks as well as providing the forcing functions or interface forces tor a 
more detailed substructure analysis. These tasks are definition of critical areas, structural margins for the 
general structural areas, forcing functions for substructure analysis, correlation with test, and identification 
of flight event design cases. 

Ultimate margins of safety are determined by multiplying the ultimate safety factor and the limit 
stress dividing this product into the material ultimate strength, and then subtracting “ 1 ” from the resulting 
quotient. Yield margins are defined similarly. Yield margins ensure operational reliability. Ultimate mar- 
gins ensure integrity under rare conditions for which there is no statistical basis. All margins of safety 

must be nonnegative. 

A case may illustrate this level of detailed analysis. During SSMC buildup at lift-off, the thrust 
induces a design bending moment on the SRB, which is resisted by the four holddown bolts at the base of 
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each SRB aft skirt. Figure 59 shows the resulting stresses on the SRB at three vehicle locations. Notice, 
the stresses peak near the holdout bolts, diminish rapidly up the SRB, and disappear near the SRB/ET 
attach ring. These nonuniform stresses are recognized as stress discontinuities, originating from abrupt 
changes in structural geometry, boundary load, thermal, or metallurgical properties. 


SRB FINITE ELEMENT MODEL 

STATION 1577 
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Figure 59. SRM stress distributions. 

5. Verification . Many aspects of verification are addressed, and summarized below. First and 
foremost, verification is accomplished both by analysis and test. It is impossible to verify every aspect of a 
design by test. Many times, an analytical model can only be verified by test for a specific design condition. 
Then this benchmarked model is used to verify the total set of design conditions. Second, verification is 
always tested against assumption, specified requirements, and criteria, and, if not satisfied, requires a pro- 
gram waiver. In general, not only must the structural limits be verified, but also most environments, 
models, etc. The process is, therefore, complicated and requires documentation to demonstrate compliance 
and program tracking. Third, some verification can only be accomplished during operational environ- 
ments. For example, the first six space shuttle flights had special instrumentation and data systems to 
verify many aspects of the system from loads to environments. This requires verification procedures from 
each discipline, system, subsystem, element, and component to thoroughly develop flight test require- 
ments for instrumentation and data outputs. Without instrumentation, it is unlikely that the shuttle would 
have discovered the orbiter wing problem or overpressure at lift-off. Posttest analyses, including 
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environmental and structural model analyses, and model update must be accomplished to ensure that 
reliable tools are available for design changes, deviation assessment, and operational constraint 
determination. 


C. Subelement and Local Analysis 

Subelement and local analysis is very critical at the level where all fracture mechanics, nondestruc- 
tive evaluation (NDE), nonlinear stress analysis, fastener analysis, stability, and critical margins are 
determined. This more indepth evaluation requires more detailed models of critical subelement and 
possible nonlinear analysis techniques. In this design phase, the modeling assumptions, code choices, 
analysis levels, linear versus nonlinearities, etc., can produce completely erroneous or very accurate pre- 
dictions. Again, design starts with the choice of model mesh, elements, and codes. This choice is based on 
the explorative or hand analyses, etc., discussed early in the design phase. Also, the use of load indica- 
tors, stress and loads transformations can be used to expedite many of these analyses. Since the analysis is 
with a more localized regime, it is critical that the finite element modeling is understood in all respects with 
used programs, codes, etc., must not be used in a black box manner, and reference 84 is a typical 
example. A brief overview of finite elements follows to provide a basis for modeling concerns. 

The finite element approach is based on the idea that a very complex problem may be broken into 
many subsets (finite elements) of single problems with simple assumptions yielding approximate solu- 
tions. With proper care in element choices, the solution will converge close to the real solution. As the 
number of elements increase so does the solution convergence. 

The FEM is developed by writing an assumed displacement-based function that gives the element 
displacement as a function of a shape function and node displacements. Relationships between displace- 
ment and strain, strain and stress, and stress and joint forces are written, then combined to give the overall 
element equation. 

The choice of elements is determined by the need to properly represent shapes, stress, etc. Key 
factors are the characteristics of the areas being modeled and whether elastic or plastic (nonlinear) analysis 
is required. For very complex analysis, many node solid elements are required. The concern should not 
only be to get design details but to ensure that basic element length, width, and depth ratios do not violate 
sound FEM principles; e.g., long, thin, deep elements usually give problems. For very large and complex 
structures (such as a shuttle element), demand or available finite element solving equipment is exceeded, 
and the total structure is subdivided according to specific considerations. These subdivisions or com- 
ponents are called substructures or subassements. 

Using these basic principles and concepts to varying degrees throughout a subelement, the sub- 
element model is constructed and validated. The interface forces that evolved from the system analysis 
through the element analysis are now used as forcing functions or force distributions on the model. This 
technique uses a combined static and dynamic analysis using a detailed FEM with greater details in the 
special regions. The subelement model size must be large enough to distribute out the loads and balance 
the equation set. Material properties, etc., must match these same details or errors result. References 68 
and 74 contain many examples of this type analysis for various space projects and other shuttle elements. 

The final analysis step uses the same approach as this subelement step using the results from the 
subelement analysis as forcing functions for a critical area within the subelement. Greater care is required 
for the very detailed model of this critical area, since both elastic and plastic (nonlinear) analytical tech- 
niques must be used. Element choices are significant. Solid elements with good shape functions and addi- 
tional nodes are required. Material characteristics and variations in critical regions are accomplished. Using 
this model (critical areas), the dynamic and stress analysis directly provides the margins of safety: addi- 
tional analyses are required using detailed data from this critical analysis step as inputs: (1) fracture 
mechanics analysis including lifetime, critical flaw size, and NDE requirements, (2) fatigue (lifetime speci- 
fications); (3) stability; (4) nonlinear plastic analysis; (5) nonlinear jointed structural analysis. 
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These analyses require judicious choice of analysis codes, materials data, and test derived 
parametric data. Bolted joints are a problem, since individual bolt loading and local yielding are not deter- 
ministic. Elastic analysis could easily show major problems when no problem exists. In other words, bad 
assumptions produce totally erroneous analysis. The starting point for fracture analysis is accurate stress at 
the potential failure locations. Many examples and additional guidelines could be given, but are beyond the 
scope of this paper. The same is true for fatigue. These analysis approaches are discussed in detail in 
NASA safety factors design documents. 66-73 


D. Operations 

The final loads cycle is not totally complete until the design (vehicle, spacecraft, or space system) 
capabilities and characteristics are manifested into operational procedures and constraints. This formulation 
of procedures and criteria ensures that the system operates correctly and within the bounds of its capability 
of preventing failures. Many examples can be given; however, the space shuttle is chosen because of its 
current operational mode. 

The space shuttle is a highly tuned system that blends basic design options with operational proce- 
dures and strength to ensure structural viability. This process, design and operation, is managed by 
Johnson Space Center with heavy involvement with MSFC and Kennedy Space Center. The shuttle design 
calls for monthly mean wind trajectory biasing coupled with pitch, yaw, roll, and elevon load relief. Even 
with these load reduction schemes, the design final ended with marginal structure (particularly the orbiter 
wing). The marginal design resulted due to the inability to predict prior to flight the aerodynamic distribu- 
tion on the vehicle. 76 To protect the vehicle structure and ensure adequate performance, the launch systems 
evaluation advisory team (LSEAT) was formed to develop, implement, and be the focus for systems 
evaluation during each space shuttle launch. 

The procedure starts the shaping of basic trajectory for each launch, using the vehicle structural 
capability as constraints at key orbiter elements. The critical shuttle element constraints are given in terms 
of load indicators (fig. 53). Figure 60 illustrates this approach for the monthly mean wind for the month of 
the scheduled launch. Using this monthly mean wind bias trajectory, the three-sigma dispersions are 



Figure 60. LSEAT overview. 
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generated for each load indicator (critical structure) for use by LSEAT during operations. These disper- 
sions are used to protect against parameter uncertainties, and to define the operations procedure. It consists 
of sending up wind sounding balloons at various intervals prior to launch, then calculating the shuttle per- 
formance and load response to these winds. The nominal values generated combine three-sigma dispersed 
values added as well as a wind persistence value to account for wind change effect at launch time. If all 
loads are under their limit values, then the decision is go for launch. If not, there is an option called 
DOLILU, to bias the trajectory further using the wind profile measurements. If the indicators are within 
limits, the launch call is still go; if not, the process is continued until the next 2-h wind profile measure- 
ment. If the limits are still unsatisfactory, the launch recommendation to the management team is no go. 

Figure 61 is a typical pitch plane wind profile plotted with the monthly mean and 95- and 99- 
percent envelope values. Figure 62 is the response of a wind indicator with the monthly mean, the nominal 
response to the latest wind profile, and the 99-percent dispersion value. The limit is plotted as a straight 
line. Many other parameters are tracked for each wind profile starting 50 h prior to launch and continuing 
until launch minus 4.25 h. 
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Figure 62 . Response of wind indicator. 

This example is a short synopsis of the launch operational procedure. The procedure continues to 
evolve as more is learned, therefore, the process as stated may not be current, but illustrates how structural 
reliability can be ensured with operations. Projects must utilize all the best tools, techniques, and experi- 
ence available from concept selection, through design, and during operation to ensure successful missions. 


XIV. CONCLUSIONS 

“In business, as most of it is constituted today, a man becomes valuable only as he 
recognizes the relation of his work to that of all his associates. One worker more or less 
makes little difference to most big organizations, and any man may be replaced. It is the 
cumulative effort that counts.” W. Alton Jones. 

“The whole art of teaching is only the art of awakening the natural curiosity of 
young minds for the purpose of satisfying it afterwards.” Anatole France. 


It was briefly illustrated through case and reference how the design process translates systems 
engineering product requirements into a component, into a blueprint, assembly, and operational procedure. 
The process, tools, and verification methods were noted to be product-specific, precluding a 
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common process for all products. However, many philosophical principles may be derived from the 
history of design and its problem solutions that should be considered in the process. Some of the 
principles are applicable to all design processes, and some address specific functions and disciplines and 
all significant ones are here concisely summarized and recommended. 


A. Summary 

• The concept selection and design process is key to a quality product 

Progressive, convergent, increasing in depth concept selection 
Sensitivity and trades to identify key parameters 
System focus 

Interdisciplinary analysis/design. 

• Requirements are the mantel that determines the product’s characteristics good and bad 

Must be challenging with minimum constraints 
Minimum change 

Minimum required to maintain order 

Leave room for creative design (do not dictate design). 

• All design is a trade/compromise between conflicting requirements 

Trades/sensitivities 
Customer needs. 

• The prime resource in design is the people, all else are tools to assist them 

Trust 

Empowerment 
Train constantly. 

• Models must be constantly challenged (assumptions) and bench marked with test data; must 
always pass the physics of the problem test 

Simple hand checks 

Benchmark 

Challenge and check assumptions 
Do not extrapolate too far 
Check numerics. 
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Models/analysis/simulations are virtual reality; reality is in the hardware/system testing; read the 
hardware — it contains the answer. 


• Lessons from the past contain proven solutions if used appropriately; used indiscriminately as 
points of departure for extrapolation can lead to major problems. 

• It is prudent to design for fatigue and fracture control especially for reusable systems 

Two different design points 

Materials characterization at right temperatures necessary 
NDE must be quantified 

Eliminate dynamic tuning as a fatigue mitigation technique 
Proof testing has merit. 

• All design must have system focus, discipline-focused skills must be sharpened and honed but 
never used in isolation 

Technical communications 

Teaming 

ICD’s. 

• Design has become a design of specializations; must move back to a design of systems based 
on the physics of the problem — simplicity is the answer. 

• Cost, operations, manufacturability, and supportability must be a fundamental part of the 
design equations; must develop metrics to support. 

• There are no small changes; effects of changes usually have large magnification factors. 

B. Recommendations 

People 

Develop, build, and maintain a learning organization 

Must work as a team with representatives from all critical design, development, and operation 
disciplines 

All great people make company with good people, not necessarily agreeable people but good 
people 

People determine the design, the hardware. 

General 

Build a library of lessons learned by categories 
Tailor all requirements 

Provide feasibility of requirements, design, and verification 
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Constraints imposed early create a suboptimized system increasing cost, etc., in operations 

Start all complex analysis with basic hand estimation 

Design hardware for inspectability and manufacturability 

Eliminate welds or design peak stress in parent material not welds 

Design and manufacture in quality; inspect for insurance 

Match methodology to the problem 

Procedure/criteria/philosophy are the backbone of design 

Institute early data basing 

Very accurate definition of the system is required if it must operate near a limit 

Phases A and B of a program must uncover critical technologies and develop approaches and 
capabilities for their solutions 

Requirements, constraints, etc., leveled early, determine the basic hardware; changes made later 
are only tuning of the original, it is nearly impossible to start over with a clean sheet of 
paper. 

Robust 

Design for robustness/simplicity 

Extreme environment variations (cycles) must be considered in long-life machine design 
Sensitivities must be identified, quantified, and optimized 

When possible, design in the linear range, achieve robustness, employ nonlinearities as the last 
resort 

Margins must be specified and validated 

Design against deterministic criteria; invoke probabilities to determine sensitivities and reliability 
Design against total cost with system optimization 

Design for flexibility — what is not designed into products must be made safe by operational con- 
straints, maintenance, etc. 

Design for insensitivity to environments (natural, induced, corrosion, etc.) or control their varia- 
tion and accurately define 

Know what is critical to the system; model, analyze, and test that area accurately. 

Dynamic 

Dynamic systems with large energy sources are very susceptible to problems 
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Dynamic tuning should be avoided 

Never neglect the potential coupling between structures, acoustics, flow, control, etc. 

Eliminate static and dynamic three-dimensional coupling where possible 
Multibody dynamic systems with low damping are susceptible to problems. 

Test 

Elimination of subsystem (element) testing and analysis leads to trouble 

Models are only as good as the assumptions made and the experimental data input 

All testing must be preceded by pretest analysis giving procedures and instrumentation, followed 
by model correlation and updating 

Limitations of analysis and test must be well understood and considered in performance audit 

Adequate instrumentation is required on all tests and flights for all critical areas; instrumentation 
should be a part of the design 

Read the hardware, it has the answers. 
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